Conversation
MH_TWOLEVEL says a linked image binds its undefined symbols against the libraries it lists rather than looking them up in a flat namespace. A relocatable object is the static linker's input: it lists no libraries and binds nothing, so no toolchain sets the flag on one and its absence says nothing about the load. The check reads the header flag alone, so since MH_OBJECT became a supported file type every relocatable object has logged an error asking the reader to open an issue about a degradation that cannot happen. Both relocatable_object.macho fixtures angr/binaries tracks trip it, and so does cle's own test_relocatable_object. Skip the message for MH_OBJECT. An image that lists libraries and still clears the flag keeps it: that is the case it was written for, and BIND_SPECIAL_DYLIB_FLAT_LOOKUP is still unhandled in symbol.py. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Validation record for head
The two suites that failed are
|
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS What cle logs while loading Mach-O files from Each file is loaded with Before — every file that clears the flag is reported, including the two cle master 7c5e1a2After — the relocatable objects are silent; the flat-namespace images, which do with this change, c4df37d |
|
Corpus decompilation diffs can be found at angr/dec-snapshots@master...angr/cle_845 |
|
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS Closing this pull request: we could not show a measured impact of this change on real binaries from our datasets, so we are withdrawing it. |
2 participants
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
Problem
Loading a Mach-O relocatable object logs an error asking the reader to open an
issue.
tests/x86_64/relocatable_object.machois one of this repository's ownfixtures, loaded by
tests/test_macho.py::test_relocatable_object:Nothing is wrong with the object: it loads with its sections, its symbols and a
base address of 0, exactly as
test_relocatable_objectasserts. Relocatableobjects are the ordinary contents of a static archive or a build tree, so the
line is noise at ERROR on a supported and correct load.
test_relocatable_objectloads two of them.
Root cause
MachO.__init__reads the header flag and nothing else:MH_TWOLEVEL says a linked image binds its undefined symbols against the
specific libraries it lists, rather than looking them up in a flat namespace. A
relocatable object is the static linker's input: it lists no dependent
libraries, carries no dyld information and has no imports, so no toolchain sets
the flag on one. On both fixtures
depsis[],imported_librariesis['Self'], every binding blob is absent and there are no imports, so the paththe message warns about —
BIND_SPECIAL_DYLIB_FLAT_LOOKUPincle/backends/macho/symbol.py, which really is unhandled — cannot be reached.The absence of the flag on an MH_OBJECT is not information.
The line came from #290, which replaced
raise CLEInvalidBinaryError("Cannot handle non MH_TWOLEVEL binaries")with it because such binaries were "veryrare". #787 then made relocatable objects loadable, and every relocatable object
clears the flag.
Fix
Skip the message when the file type is MH_OBJECT, and leave every other case
alone. An image that lists libraries and still clears the flag keeps reporting:
that is what #290 was written for.
Deliberately not done: the wording and the ERROR level of the remaining message
are unchanged, and no flat-namespace binding is implemented here.
Testing
tests/test_macho.py::test_relocatable_object_is_not_reported_as_flat_namespaceloads both
relocatable_object.machofixtures and asserts that nothing at ERRORmentions MH_TWOLEVEL, then loads
tests/aarch64/langdetect_go.machoand assertsthat it still does. On master it fails on that first MH_TWOLEVEL assertion, at
the aarch64 fixture, with the message above. The before and after are in the
output comment.
Validation: #845 (comment)
session: sharpen