segment_command’s fileoff doesn’t correspond to section’s offset in images loaded from the dyld shared cache

Originator:mark
Number:rdar://26864860 Date Originated:2016-06-17
Status:Open Resolved:
Product:OS X Product Version:10.12dp1 16A201w
Classification:Other Bug Reproducible:Always
 
Summary:
Normally, in a Mach-O image, the values carried in segment_command[_64]::fileoff and section::offset are offsets from the beginning of an image file.

Historically, in the dyld shared cache, these fields were updated to be relative to the beginning of the mapped dyld shared cache. This was done for all segments and sections except for the __TEXT segment and any section within that segment. See 10.11.2 dyld-360.18/launch-cache/update_dyld_shared_cache.cpp. In that version, there are two comments that say “don't alter __TEXT until <rdar://problem/7022345> is fixed”. The original mach_header[_64]-relative values are retained for the __TEXT segment.

Now, in 10.12dp1 16A201w, I’m seeing a new behavior. segment_command[_64]::fileoff is still relative to the Mach-O image file for a __TEXT segment (unaltered from the original uncached image), but within that segment, section[_64]::offset values are all relative to the start of the dyld shared cache file.

This is causing a problem for my code that expects segment_command[_64]::fileoff and section[_64]::offset values to be relative to the same base within a single segment.

I don’t know what’s going on inside radar 7022345, but in all cases, it should remain possible to treat all offset values in both segment_command[_64] and section[_64] as relative to the same base, at least within the same segment.

https://crashpad.chromium.org/bug/118

Version:
10.12dp1 16A201w

Comments

06-Jul-2016 01:16 PM

We haven’t fixed it, we worked around it by not considering this field.

It would be best if the field appeared valid in memory. As it stands now, it is no longer possible to make sense of this value (for example, to validate the module as a test against memory corruption) on 10.12.

By mark at July 6, 2016, 5:17 p.m. (reply...)

Apple Developer Relations01-Jul-2016 04:01 PM

We understand that you have already fixed this.

Please let us know whether the issue is resolved for you by updating your bug report.

By mark at July 6, 2016, 5:16 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!