macaw/macaw-ppc/tests/ppc/test-indirect-calls.s.expected

R { funcs = [ (0x100001d0, [ (0x100001d0, 84)
                           , (0x10000224, 12)
                           , (0x10000230, 44)
                           , (0x1000025c, 32)
                           ])
            , (0x10000180, [ (0x10000180, 68)
                           ])
            , (0x10000148, [ (0x10000148, 44)
                           ])
            ]
  , ignoreBlocks = [0x1000027c]
  }
Add a (currently failing) test for indirect call handling The code pointer discovery in macaw can't handle this case because we never write the code pointers into memory - we only read them. We really need a way to tell macaw about code pointers. The easy workaround is to pull all of the function entry points out of the TOC and just seed the macaw search with them, but it would be nice to be able to identify them from first principles. 2017-11-15 06:00:01 +03:00			`R { funcs = [ (0x100001d0, [ (0x100001d0, 84)`
ppc: Fix some expected test output Recent changes in macaw(-base) mean that we split blocks more aggressively. The old expected outputs were conservative - these new values are much more in line with intuitive expectation (with more aggressive splitting of blocks and less code duplication between blocks). 2018-03-24 01:14:54 +03:00			`, (0x10000224, 12)`
Add a (currently failing) test for indirect call handling The code pointer discovery in macaw can't handle this case because we never write the code pointers into memory - we only read them. We really need a way to tell macaw about code pointers. The easy workaround is to pull all of the function entry points out of the TOC and just seed the macaw search with them, but it would be nice to be able to identify them from first principles. 2017-11-15 06:00:01 +03:00			`, (0x10000230, 44)`
			`, (0x1000025c, 32)`
			`])`
			`, (0x10000180, [ (0x10000180, 68)`
			`])`
			`, (0x10000148, [ (0x10000148, 44)`
			`])`
			`]`
			`, ignoreBlocks = [0x1000027c]`
			`}`