I went to implement objcopy’s --prefix-symbol support for MachO binaries and was a bit surprised by the behavior of it with elf binaries (which matches binutils’ objcopy as well). Prefixing applies to all symbols, including undefined symbols, meaning something as simple as this example, will not work:
% cat /tmp/main.c
#include <stdio.h>
int main() {
printf("hi\n");
}
% clang /tmp/main.c -o /tmp/main.o
% llvm-objcopy --prefix-symbols=bar /tmp/main.o
% clang /tmp/main.o
/usr/bin/ld: error in /tmp/main.o(.eh_frame); no .eh_frame_hdr table will be created
/usr/bin/ld: /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
While prefixing main specifically might not be a common use case, my expected use case for this would be to prefix symbols in a static library, which has a similar issue for undefined symbols:
/usr/bin/ld: prefixed.o:(.data+0x6b0): undefined reference to `barmunmap'
/usr/bin/ld: prefixed.o:(.data+0x6c8): undefined reference to `barmremap'
/usr/bin/ld: prefixed.o:(.data+0x6f8): undefined reference to `barreadlink'
/usr/bin/ld: prefixed.o:(.data+0x710): undefined reference to `barlstat64'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-objcopy’s ELF behaviour is closely modelled on GNU objcopy’s behaviour, with the intent that it is a drop-in replacement for that tool. There are a limited number of exceptions to this, but --prefix-symbols is not one of them. When using GNU objcopy v2.30, I get the following behaviour:
$ cat test.cpp
void foo();
int main(){
foo();
}
$ gcc -c test.cpp
$ nm test.o
U GLOBAL_OFFSET_TABLE
0000000000000000 T main
U Z3foov
$ objcopy test.o test.prefix.o --prefix-symbols=bar
$ nm test.prefix.o
U bar_GLOBAL_OFFSET_TABLE
0000000000000000 T barmain
U bar_Z3foov
I agree with you that I don’t know under what situations this behaviour can be useful, apart from some pretty niche cases. Perhaps worth raising on the GNU mailing list?
llvm-objcopy's ELF behaviour is closely modelled on GNU objcopy's
behaviour, with the intent that it is a drop-in replacement for that tool.
There are a limited number of exceptions to this, but --prefix-symbols is
not one of them. When using GNU objcopy v2.30, I get the following
behaviour:
$ cat test.cpp
void foo();
int main(){
foo();
}
$ gcc -c test.cpp
$ nm test.o
U _GLOBAL_OFFSET_TABLE_
0000000000000000 T main
U _Z3foov
$ objcopy test.o test.prefix.o --prefix-symbols=bar
$ nm test.prefix.o
U bar_GLOBAL_OFFSET_TABLE_
0000000000000000 T barmain
U bar_Z3foov
I agree with you that I don't know under what situations this behaviour can
be useful, apart from some pretty niche cases. Perhaps worth raising on the
GNU mailing list?
James
The upside of the behavior is:
relocatable_link(prefix_symbols(a.o), prefix_symbols(b.o)) = prefix_symbols(relocatable_link(a.o, b.o))
I.e. make symbol resolution work for the symbol set within the library.
That said, I think in most times --prefix-symbols is not useful.
Users need --redefine-syms which apply to a selective set of symbols, it
is very difficult to rule out: