Mach-O: Register the LC_FUNCTION_STARTS entries as function hints - #754
Mach-O: Register the LC_FUNCTION_STARTS entries as function hints#754zardus wants to merge 1 commit into
Conversation
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Validation record for head
What the entries are, and why this is a hint source of its own rather than a symbol table. Measured on a GHC-produced x86-64
The 129 are the reason for the ordering note in the description: the table names data atoms as well as functions, and the labels above come from the producer's own naming rather than from anything angr or this branch computes. Caveats: the address is recorded as the linked virtual address and rebased with the object, matching the ELF FDE hints; a 32-bit ARM Mach-O records the Thumb bit in the entry, which this branch passes through untouched. Merge order, measured on the angr side against |
|
Corpus decompilation diffs can be found at angr/dec-snapshots@master...angr/cle_754 |
The backend parses LC_FUNCTION_STARTS into lc_function_starts and then uses it for nothing, so a Mach-O object hands its consumer no function hints at all while an ELF one gets a hint for every FDE in .eh_frame. On a stripped image the table is the only record of where the functions begin. Each entry becomes a FunctionHint under a new FunctionHintSource.FUNCTION_STARTS. It is a source of its own rather than an export or an unwind record because ld64 records the address of every atom it placed in an executable section, and a producer's data atoms -- a Haskell closure's info table, a Swift offset table -- are atoms like any other, so the consumer has to be able to tell this table apart from one that names only functions. No size is recorded. The distance to the next entry is not a function length: one function can hold several atoms, and a consumer that reads the gap as a size gets a boundary the file never stated.
b987439 to
95b7c8f
Compare
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
The Mach-O backend parses
LC_FUNCTION_STARTSintolc_function_startsand then uses it for nothing, so a Mach-O object hands its consumer no function hints at all while an ELF one gets a hint for every FDE in.eh_frame. On a stripped image that table is the only record of where the functions begin.Each entry now becomes a
FunctionHintunder a newFunctionHintSource.FUNCTION_STARTS. It is a source of its own rather than an export or an unwind record because ld64 records the address of every atom it placed in an executable section, and a producer's data atoms are atoms like any other, so a consumer has to be able to tell this table apart from one that names only functions. No size is recorded: the distance to the next entry is not a function length.The test checks the hints on
tests/aarch64/dyld_ios15.machoagainst the parsed table and against the bounds of__TEXT,__text.Land this before angr/angr#6861, which decides which of these entries to use. Until that one lands angr takes every hint that is not an FDE as a function start, which on a Haskell image puts function heads on 129 info tables; the reverse order does not work at all, because angr#6861 reads a hint source this pull request adds.
Fixes #750. Validation: #754 (comment)