5 ms·

I wonder how many folks are aware that ELF shared libraries and ELF executables are the exact same thing? There's no substantial compiling or decompiling neces

I wonder how many folks are aware that ELF shared libraries and ELF executables are the exact same thing? There's no substantial compiling or decompiling necessary to go from shared object to executable and back. One need only add or remove the appropriate symbols from the object and (perhaps even optionally) change the object type. Have you ever tried to directly execute your libc.so.6 on a linux system? You can. There's nothing at all novel about this process, other than making it easy for folks who've never read the manual for their linker. Edit: Someone downvoted this observation; I imagine they think I'm unfairly trivializing this so I'll add: Read the source code. This tool we're discussing is a simple ~100 line program. It's not complicated: https://github.com/endrazine/wcc/blob/master/src/wld/wld.c https://github.com/endrazine/wcc/blob/master/src/wld/wld.c

colanderman 10y ago
I don't get it. Isn't there a missing step of making the objects relocatable (i.e. what -fPIC does)? That requires rewriting branches and stuff. But clearly wcc isn't doing this?
- vidarh 10y ago
  PIC makes the code position independent. That is, the code can be moved without relocation fixups. ELF executables typically use relocatable code (with relocation sections) rather than PIC because especially on i386 it has performance and size implications to use -fPIC. But on x86_64 it's actively discouraged, but not actually prevented if you generate an ELF file that the linker is satisfied with. The main issue with that latter part is that 64 bit code can contain 32 bit relocation fixups, and such addresses will be impossible for the linker to relocate outside the 32 bit memory space, and your mileage may vary whether your load time linker will be able to even try to handle that or not on a 64 bit platform. If your code is free of 32 bit relocations, there "shouldn't" be any reasons for them not to be usable as shared objects even if they contain relocations instead of use PIC (whether any specific load time linkers unnecessarily enforce restrictions on this is another matter).

colanderman 10y ago

I don't get it. Isn't there a missing step of making the objects relocatable (i.e. what -fPIC does)? That requires rewriting branches and stuff. But clearly wcc isn't doing this?

vidarh 10y ago
PIC makes the code position independent. That is, the code can be moved without relocation fixups. ELF executables typically use relocatable code (with relocation sections) rather than PIC because especially on i386 it has performance and size implications to use -fPIC. But on x86_64 it's actively discouraged, but not actually prevented if you generate an ELF file that the linker is satisfied with. The main issue with that latter part is that 64 bit code can contain 32 bit relocation fixups, and such addresses will be impossible for the linker to relocate outside the 32 bit memory space, and your mileage may vary whether your load time linker will be able to even try to handle that or not on a 64 bit platform. If your code is free of 32 bit relocations, there "shouldn't" be any reasons for them not to be usable as shared objects even if they contain relocations instead of use PIC (whether any specific load time linkers unnecessarily enforce restrictions on this is another matter).