Previously llvm-strip would fail because of unknown commands.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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.
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
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
@alexander-shaposhnikov mind checking this one out? related to the other load command update
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!