libobjc-trampoline.dylib is not a well-formed Mach-O image

Originator:mark
Number:rdar://42340211 Date Originated:2018-07-18
Status:Open Resolved:
Product:macOS + SDK Product Version:10.14db4 18A336e
Classification:Other Bug Reproducible:Always
 
Area:
Something not on this list

Summary:

libobjc-trampoline.dylib is new in macOS 10.14 (“Mojave”). It’s got a weird symbol table that’s inconsistent with the load commands.

The symbol __objc_blockTrampolineEnd_stret, which purports to be in section __TEXT,__text per the symbol table, is at offset 0x3000. This is actually in section __TEXT,__unwind_info.

I noticed this while testing Crashpad, Google’s crash reporting client, for 10.14 compatibility. The Crashpad crash handler accesses Mach-O images from out of process by reading the crashing process’ memory. It understands the structure of Mach-O images and their symbol tables. Its symbol table reader flags any symbols where there’s a discrepancy between the section that the symbol table says the symbol is in and the section that the symbol is actually in.

https://crashpad.chromium.org/bug/242 tracks the problem on our end.

As you can see from the nm invocation below, __objc_blockTrampolineEnd_stret has value 0x3000, and the symbol table says that it’s in __TEXT,__text. However, the otool invocation shows that __TEXT,__text begins at 0x1000 and is length 0x2000, placing 0x3000 one byte outside of this section. 0x3000 is actually the starting address of __TEXT,__unwind_info.

This occurs in all three architectures of the fat file.

I also note that both __objc_blockTrampolineEnd and __objc_blockTrampolineImpl_stret share the same address. This may be fine, but it may also be suspicious.

litterbox@litterbox zsh% nm -mp /usr/lib/libobjc-trampolines.dylib
0000000000002000 (__TEXT,__text) external __objc_blockTrampolineEnd
0000000000003000 (__TEXT,__text) external __objc_blockTrampolineEnd_stret
0000000000001000 (__TEXT,__text) external __objc_blockTrampolineImpl
0000000000002000 (__TEXT,__text) external __objc_blockTrampolineImpl_stret
0000000000001020 (__TEXT,__text) external __objc_blockTrampolineStart
0000000000002020 (__TEXT,__text) external __objc_blockTrampolineStart_stret
                 (undefined) external dyld_stub_binder (from libSystem)

litterbox@litterbox zsh% otool -l /usr/lib/libobjc-trampolines.dylib
/usr/lib/libobjc-trampolines.dylib:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x00           6    15        744 0x02100085
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 232
  segname __TEXT
   vmaddr 0x0000000000000000
   vmsize 0x0000000000004000
  fileoff 0
 filesize 16384
  maxprot 0x00000007
 initprot 0x00000005
   nsects 2
    flags 0x0
Section
  sectname __text
   segname __TEXT
      addr 0x0000000000001000
      size 0x0000000000002000
    offset 4096
     align 2^12 (4096)
    reloff 0
    nreloc 0
     flags 0x80000400
 reserved1 0
 reserved2 0
Section
  sectname __unwind_info
   segname __TEXT
      addr 0x0000000000003000
      size 0x0000000000000048
    offset 12288
     align 2^2 (4)
    reloff 0
    nreloc 0
     flags 0x00000000
 reserved1 0
 reserved2 0

Version/Build:

10.14db4 18A336e

Comments

2018-08-29 01:58 from Apple

Engineering has provided the following feedback regarding this issue:

libobjc-trampolines' assembly code put a symbol after the last instruction of a function. That function also happened to be the last bytes of the last page of TEXT, so that after-the-end symbol pointed outside the TEXT.

Later Mojave betas changed that symbol to a symbol that pointed at the last instruction. You should not see this symbol outside TEXT now.

Multiple symbols pointing to the same address are expected; your tools should be prepared to handle that.

By mark at Aug. 29, 2018, 1:01 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!