OSDev.org

I don't think you can force LD not to align sections in your file; at least I don't know if there is any command line option to do that (-z common-page-size and -z max-page-size also affect the VMA alignment).

You could try to compress the resulting ELF file; that should get rid of all padding.

Thanks. Doing relocations is the way then. It's harder, but gives much more power for the utility.

Why do you need relocation? Don't you just need to change file offsets while leaving virtual addresses invariant? ELF executable files cannot be relocated, you would essentially need to write your own linker to do that (which is a lot of work, especially when you want to support all those GNU extensions to ELF).

Korona wrote:Why do you need relocation? Don't you just need to change file offsets while leaving virtual addresses invariant? ELF executable files cannot be relocated, you would essentially need to write your own linker to do that (which is a lot of work, especially when you want to support all those GNU extensions to ELF).

The problem is in that for PE the first thing that goes at the start of an image is a set of headers, varying in size, it depends on the section count. For Elf it's a text segment, code section basically. I need to guess the size of headers when linking an elf file, and tell Elf linker put code section at my ImageBase+delta. Conceptually it's quite OK, practically it turns ugly and error prone.
Applying relocations to an Elf executable is possible. You need to tell the linker to preserve relocations. There is such an option. They don't prohibit executable be relocated, they say "typically" it has an absolute address, as well as they don't dictate "shared objects" be PIC, again - only "typically" they are. But hey, all that got plt as well as the whole dynamic linking thing in Elf is just pfff. PE mechanism for dynamic linking is so much easier.
But with the relocation capable utility, everything gets much more comfortable, you just tell your utility the desired Image Base and section alignment and it happily puts it all there (into VA space). without worrying about where the elf linker has put them. I wasted much more time trying to "guess right" Image Base in my utility analyzing the Elf input than it would take for me to learn about relocations. Applying relocations is a quite straight forward process.

I see. I didn't know GNU LD had such an option, that is quite interesting.

Yes, ELF dynamic linking via GOT and PLT is quite complicated but as a result a) lazy binding is made possible, b) the text segment is read-only, even during relocation and c) as a result of b), the text segment can truly be shared among different processes, even if the base addresses of the shared object inside these processes differ.

Korona wrote: I see. I didn't know GNU LD had such an option, that is quite interesting.

from the gnu ld manual page.

-q
--emit-relocs

Leave relocation sections and contents in fully linked executables. Post link analysis and optimization tools may need this information in order to perform correct modifications of executables. This results in larger executables.

This option is currently only supported on ELF platforms.

Yes, ELF dynamic linking via GOT and PLT is quite complicated but as a result a) lazy binding is made possible, b) the text segment is read-only, even during relocation and c) as a result of b), the text segment can truly be shared among different processes, even if the base addresses of the shared object inside these processes differ.

PE has a notion of "delayed import" which probably serves the same purpose, but doesn't require PIC.
PE text sections among others are really read only too.
there might be some effort applied to make the same DLL have the same Image Base for different processes' images consuming them. It's easy for "system DLLs", but not impossible for any else. It's a broad area for investigating. But then "real" sharing RO ages are possible for PE images.