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: Mon, 17 Apr 2000 17:58:49 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Mon, Apr 17, 2000 at 05:52:06PM -0700, Ian Lance Taylor wrote:
   > But that is not what the poster who started this thread was talking
   > about.  He was compiling the kernel with -ffunction-sections, so he
   > had many sections with many names.  It didn't work because those
   > sections didn't wind up in the expected order.

   Yes, but that is hardly incriminating against the kernel developers
   against whom you directed your invective.  We had .text and .fixup
   in strict lock-step, and we knew it.

Well, sure.  I only directed my invective against whoever created the
problem.  I apologize for any offense.


Still, the current system is not terribly flexible, and it does appear
to prohibit operations like sorting functions to put rarely used
functions together in the same memory pages, unless you break the
functions out into different source files.

The important thing seems to be to have an exception table which maps
text addresses to fixup addresses, and which permits fast lookup by
text address.  Presumably it is desirable to keep this table out of
line of the main code, and it is desirable to not have to initialize
it at boot time.

I would be inclined to use a post-processor to patch up the __ex_table
section.  This would provide complete flexibility, and you could
create a closed hash table and get even faster lookups.  The
post-processor could be written using BFD or libelf, or simply using
objcopy -s to extract the section (admittedly in an inconvenient
format) and objcopy --add-section to add it back (this would require
keeping the section the same size).

Ian

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