Re: How to stop --gc-sections nukeing all sections?

[greyham at research dot canon dot com dot au (Graham Stoney)]

Hi Ian,

After many hours further study, I've got more answers, which have led to a new
set of questions...

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.

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:

diff -ur binutils-000330/ld/emultempl/elf32.em binutils-000330.hack/ld/emultempl/elf32.em
--- binutils-000330/ld/emultempl/elf32.em	Tue Feb 29 16:53:53 2000
+++ binutils-000330.hack/ld/emultempl/elf32.em	Fri Apr  7 15:54:13 2000
@@ -978,6 +978,7 @@
   if (snew == NULL)
       einfo ("%P%F: output format %s cannot represent section called %s\n",
 	     output_bfd->xvec->name, outsecname);
+#if 0	/* This reshuffling reorders input file sections! */
   if (place->bfd_section != NULL)
     {
       for (pps = &output_bfd->sections; *pps != snew; pps = &(*pps)->next)
@@ -986,6 +987,7 @@
       snew->next = place->bfd_section->next;
       place->bfd_section->next = snew;
     }
+#endif
 
   /* Start building a list of statements for this section.  */
   old = stat_ptr;

Regards,
Graham
-- 
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929