I am trying to change some (macho arm64) symbols’ names by using LLVM-objcopy --redefine-syms.
And it gives me an output file without any warring or wrong information.
But the output file seems to be arm32. Does anyone have any ideas for this?
Interesting, can you provide a repro case. Here’s my simple attempt at reproducing this:
% cat /tmp/bar.c
void foo() {}
% clang -c /tmp/bar.c -o /tmp/bar
% nm /tmp/bar
0000000000000000 T _foo
0000000000000000 t ltmp0
0000000000000008 s ltmp1
% file /tmp/bar
/tmp/bar: Mach-O 64-bit object arm64
% cat /tmp/bar.txt
_foo prefix_foo
% llvm objcopy --redefine-syms=/tmp/bar.txt /tmp/bar
% nm /tmp/bar
0000000000000000 t ltmp0
0000000000000008 s ltmp1
0000000000000000 T prefix_foo
% file /tmp/bar
/tmp/bar: Mach-O 64-bit object arm64
--redefine-syms is definitely handled by the macho code, but I don’t expect many folks are using it.
The binutils objcopy you’re using there is from binutils not llvm. If you’d like to use LLVM’s you’ll need to brew install llvm and use llvm-objcopy which it installs.
I’m sure I used llvm-objcopy. Actually, I had compiled llvm from the source code. Besides, macOS doesn’t have objcopy.
Perhaps you need more details. Now I have tried again.
Here is the location of LLVM
/Users/se-mac/Desktop/xxxx/llvm_all/bin
Here is the command I used.
/Users/se-mac/Desktop/xxxx/llvm_all/bin/objcopy --redefine-sym _SSL_CTX_set_srp_cb_arg=_test_SSL_CTX_set_srp_cb_arg libssl.a libnew.a
Here is the information about these static libraries.
(Although the result of lipo says libnew.a's architecture is still arm64. The length of symbols' address is different)
se-mac@SE-MAC-xxxx openssl-1.1.1c % lipo -info libssl.a
Non-fat file: libssl.a is architecture: arm64
se-mac@SE-MAC-xxxx openssl-1.1.1c % file libssl.a
libssl.a: current ar archive random library
se-mac@SE-MAC-xxxx openssl-1.1.1c % lipo -info libnew.a
Non-fat file: libnew.a is architecture: arm64
se-mac@SE-MAC-xxxx openssl-1.1.1c % file libnew.a
libnew.a: current ar archive random library
I got a warning during Xcode link progress. It didn’t recognise the file header 0x21 0x3C 0x61 0x72 0x63 0x68 0x3E 0x0A 0x5F 0x5F 0x2E 0x53 0x59 0x4D 0x44 0x45.
Then I checked these libraries’ binary forms. They are quite different.
Can you run llvm-objcopy --version? At least for simple cases with LLVM @ HEAD I cannot reproduce this issue.
Here is the x86_64 version information.
(We compiled both arm64 and x86_64 llvm-objcopy, from the same source code.)
That’s from LLVM 10 which is over a year old and likely didn’t have good M1 support, can you test with HEAD or LLVM 13? https://github.com/llvm/llvm-project/releases/tag/llvmorg-13.0.0
When I changed to 13.0.0-llvm-objcopy, it worked with option – redefine-sym.
Though there is a tiny question, that it shows an error if we use “prefix-symbols”.
Whatever, we finally got this problem done. It gives us a lot of convenience. Thanks so much.
hi, this is the llvm-objcopy doc link: https://llvm.org/docs/CommandGuide/llvm-objcopy.html; Here is a clear description that prefix-symbols is an optional parameter of the ELF type, so shows an error
Does llvm-objcopy support the modification of objective-c symbols?
When I try --redefine-sym, I get error: unsupported load command (cmd=0x2d)
I’m not a Mach-O developer, but do review most of the llvm-objcopy contributions. I believe --redefine-sym is implemented for Mach-O, but it is possible there are some other issues that llvm-objcopy runs into, which haven’t been resolved yet. What version are you using? If not the HEAD of LLVM, what happens if you try the tip of the main branch?
I actually went to implement --prefix-symbols here ⚙ D113735 [llvm-obcopy][MachO] Add --prefix-symbols support but based on the discussion there, and the linked discussion from the mailing list, I dropped it since it didn’t seem like a useful flag for most cases. If you have a good use case for this we should re-open and finish that patch. Let me know!
Not being able to use redefine-sym with your case seems to have been a bug, I’ve submitted ⚙ D118526 [llvm-objcopy][MachO] Ignore LC_LINKER_OPTION when redefining symbols to fix it