RFC: linker enhancements
Jakub Jelinek
jakub@redhat.com
Fri Dec 12 13:30:00 GMT 2003
Hi!
I wonder what do you think about following:
1) with all the memory layout patches in the kernel, prelink, various
placements of vdso, programs which rely on specific memory area
to be available IMHO just should have a PT_LOAD p_filesz == 0,
p_vaddr start of the region they want to reserve, p_memsz = needed_size,
p_flags 0 program header (which will mean a PROT_NONE mapping which the
program after starting up can unmap or overmap with something else).
Without that a) ld.so can be mapped in that area by the kernel
even before ld.so is given control b) ld.so can map there shared
libraries or anonymous mappings etc. before the application is
given control.
Example of such programs is wine, which I believe needs all memory below
the executable reserved (say 4K ... 0x8000000 on IA-32).
Now, I believe one can do all of this even with current linker script,
but it will be horrible, because when there is PHDRS command in the
linker script, suddenly you have to write everything yourself and
take care of segments like PT_GNU_EH_FRAME, PT_GNU_STACK and many
others.
What do you think about e.g. adding AUTO PHDRS subcommand, which would
mean create the usual segments plus the listed one in addition to that.
Sections explicitely bound to the listed segments would go in them,
the rest would go as usual to normal segments.
Or do you have better ideas how to make building such apps easier?
2) addition of shared libraries only if referenced.
E.g. for libgcc_s for C dynamically linked programs which are using
-fexceptions (which is quite rare these days), GCC currently links
in libgcc_eh.a. It would be better to link against libgcc_s in that
case (so that there is just one unwinder etc.), on the other side
for the 99% of C dynamically linked programs which don't need it
linking against a shared library they don't use is a waste.
I think this could be solvable either by new linker script
input command variant and/or new cmdline options which would turn
this behaviour on/off.
Statically linked binaries then would be linked with
--start-group -lgcc -lgcc_eh -lc --end-group and dynamically
linked ones with
-lgcc --start-only-if-used -lgcc_s --end-only-if-used -lc \
-lgcc --start-only-if-used -lgcc_s --end-only-if-used
Jakub
More information about the Binutils
mailing list