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: How to stop --gc-sections nukeing all sections?


   Date: Fri, 7 Apr 2000 16:35:42 +1000 (EST)
   From: greyham@research.canon.com.au (Graham Stoney)

   Ian Lance Taylor writes:
   > It's possible that the linker will tend to reverse the order of input
   > sections which are not mentioned in the linker script and which thus
   > cause their own output section to be created.  I'm not sure.

   This is indeed the problem. The kernel build has an intermediate link stage
   using ld -r, which is where the sections are getting scrambled.

I see.  It's because ld -r doesn't mention these sections in the
linker script.  Nor can it.

   The problem is the reshuffling code in ld/emutempl/elf32.em:gld*_place_orphan.
   It's attempting to keep sections together, but scrambles their order in the
   process. I think that's pretty nasty: input sections should generally appear
   in the same order in the output. Here's a simple patch to "fix" it in elf32.em;
   the same approach is used in other .em files as well:

Your patch works OK for ld -r, because in an object file the order of
the sections is irrelevant (except for considerations like yours).  I
don't think it is right when doing a final link.  You aren't seeing a
problem because when doing a final link the input sections do appear
in the linker script, and thus the code in question does not get
called.

The problem here is simply that new sections are added at the start,
not the end.  I suspect we can fix it by simply adding
    pps = &(*pps)->next
after the loop which sets pps in the first place.

Ian

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