This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objcopy][MachO] Add llvm-strip support for newer load commands
ClosedPublic

Authored by keith on Nov 11 2021, 10:37 PM.

Diff Detail

Event Timeline

keith created this revision.Nov 11 2021, 10:37 PM
keith requested review of this revision.Nov 11 2021, 10:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 11 2021, 10:37 PM

I'm not sure how this should be tested since there aren't cases where we actually link binaries before being able to run this

I'm not sure how this should be tested since there aren't cases where we actually link binaries before being able to run this

I'm not too familiar with the Mach-O side of llvm-objcopy, but a quick search shows that at least some (possibly all) of the existing load commands are tested using yaml2obj-generated inputs. Take a look at the eixsting tests like lc-load-weak-dylib.test. If yaml2obj support needs to be extended for the new load commands, it should be fairly simple to do so.

I'm not sure how this should be tested since there aren't cases where we actually link binaries before being able to run this

Just last week I added a new option to obj2yaml to dump the entire raw LINKEDIT/DATA segment of a binary. Maybe this is helpful here.

keith added a comment.Nov 12 2021, 1:02 PM

I'm not sure how this should be tested since there aren't cases where we actually link binaries before being able to run this

I'm not too familiar with the Mach-O side of llvm-objcopy, but a quick search shows that at least some (possibly all) of the existing load commands are tested using yaml2obj-generated inputs. Take a look at the eixsting tests like lc-load-weak-dylib.test. If yaml2obj support needs to be extended for the new load commands, it should be fairly simple to do so.

Yea this make sense, my problem is that the failure case I hit while testing this was that the strip would succeed, but the binary would be malformed because of these offsets being incorrectly calculated, and fail to execute. So I need to come up with some thorough before and after for that I guess

keith added a comment.Nov 12 2021, 1:55 PM

I'm not sure how this should be tested since there aren't cases where we actually link binaries before being able to run this

Just last week I added a new option to obj2yaml to dump the entire raw LINKEDIT/DATA segment of a binary. Maybe this is helpful here.

I'm not sure what the backwards compat should be with previous versions of nm (or maybe just apple's cctools version in general), but it looks like there are some issues with this today:

% echo "int main() { return 0; }" > /tmp/bar.c
% clang /tmp/bar.c -o /tmp/main
% nm /tmp/main
0000000100000000 T __mh_execute_header
0000000100003fa4 T _main
% ./bin/obj2yaml /tmp/main | ./bin/yaml2obj > /tmp/new
% nm /tmp/new
LLVM ERROR: bad chained fixups: unknown imports format: 0
zsh: abort      nm /tmp/new
keith updated this revision to Diff 386951.Nov 12 2021, 2:12 PM

Add test case

keith added a comment.Nov 17 2021, 9:57 AM

@alexander-shaposhnikov mind checking this one out? related to the other load command update

This revision is now accepted and ready to land.Nov 17 2021, 10:36 AM

@keith is there a reason Object::ExportsTrie was added instead of reusing the Exports member? I read in D107673 that LC_DYLD_EXPORTS_TRIE and LD_DYLD_INFO are mutually exclusive, so we could re-use the same trie for both load commands.

Herald added a project: Restricted Project. · View Herald TranscriptJul 11 2022, 12:41 AM
keith added a comment.Jul 11 2022, 1:22 PM

@keith is there a reason Object::ExportsTrie was added instead of reusing the Exports member? I read in D107673 that LC_DYLD_EXPORTS_TRIE and LD_DYLD_INFO are mutually exclusive, so we could re-use the same trie for both load commands.

Interesting! I didn't consider this option when I was writing this IIRC, I was just mirroring the 1:1 command to member. So if that works that sounds fine to me!