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