This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: output order of input sections not named in linker script


   Date: Mon, 12 Jul 1999 23:39:34 -0400
   From: Roland McGrath <roland@frob.com>

   I am contemplating what happens with input sections whose names do not
   appear in the linker script at all.

   ld.texinfo says:

	If you do not use a @code{SECTIONS} command in your linker script, the
	linker will place each input section into an identically named output
	section in the order that the sections are first encountered in the
	input files.  If all input sections are present in the first file, for
	example, the order of sections in the output file will match the order
	in the first input file.  The first section will be at address zero.

This is a documentation bug.  It isn't always true.  The linker
emulation can override this, and the ELF emulation does.  The ELF
emulation tries to put the section in a reasonable location based on
its attributes.

   The behavior I see is that read-only sections are put at the end of the
   text segment, and writable sections are put at the end of the data segment
   (before bss).  (That much is in fact the reasonable default I wanted,
   though not what the documentation seems to say it will do.)  Within the
   unmentioned read-only sections and within the unmentioned writable
   sections, it appears to locate the output sections in the reverse of the
   order in which input sections of that name first appeared in the link.

This is more or less how I would expect it to behave, although putting
the output sections in reverse order does seem vaguely wrong.

The work is done by gld${EMULATION_NAME}_place_orphan in
ld/emultempl/elf32.em.

   Is it supposed to behave this way?  Is there supposed to be no guarantee at
   all about the order of the unmentioned sections in the output?

I don't know.  I'm certainly open to the possibility that the linker
behaviour should be changed.  The current behaviour is meant to
implement reasonable defaults.  This is useful for ELF, because code
like glibc uses lots of random section names which do not occur in
typical linker scripts.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]