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: PATCH for IRIX6/linkonce sections


   From: Mark Mitchell <mark@codesourcery.com>
   Date: Mon, 19 Jul 1999 09:48:39 -0700

   >>>>> "Ian" == Ian Lance Taylor <ian@zembu.com> writes:

       Ian> This sort of thing is what OTHER_RELOCATING_SECTIONS is for.
       Ian> Will it work to just define that in elf32bmipn32.sh?

   I don't think so, but perhaps I'm wrong.

   You'll have to help me a little bit.  In the rest of elf.sc, all of
   the linkonce things are handled roughly like:

     .data ${RELOCATING-0} : {
       *(.data)
       *(.data*)
       ${RELOCATING+*(.gnu.linkonce.d*)
     }

   In other words, some combination happens even when producing a
   relocateable object (the first two lines); some other combination
   happens only when RELOCATING (i.e., when producing a non-relocateable
   object) in the last line.

   I think the .MIPS.events/.MIPS.content stuff needs to be handled
   analagously.  So, OTHER_RELOCATING_SECTIONS isn't good enough; it
   doesn't apply when not relocating.

The .data* stuff doesn't have anything to do with .gnu.linkonce
sections.  That is there to handle cases in COFF where the relocation
count for a section overflows, and so multiple sections must be built
when generating a relocateable object file.

You probably do not need any equivalent to *(.data*) in your MIPS ELF
specific sections.

So that leaves us with

     .data ${RELOCATING-0} : {
       *(.data)
       ${RELOCATING+*(.gnu.linkonce.d*)
     }

If you don't name a input section in a linker script at all, the
default is to combine all the input sections of that name into an
output section of the same name.

So you shouldn't need any special behaviour when doing a relocateable
link.  You should only need special behaviour (including the
.gnu.linkonce sections) when doing a final link.  Therefore, it should
work to use OTHER_RELOCATING_SECTIONS, and use definitions which are
the equivalent of

     .data ${RELOCATING-0} : {
       *(.data)
       *(.gnu.linkonce.d*)
     }

In any case, if my argument is wrong somewhere, I think it would be
better to create something analogous to OTHER_RELOCATING_SECTIONS.
For example, you could define OTHER_RELOCATEABLE_SECTIONS or
something, and then define both with various duplications.

Ian

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