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

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

Hi guys,

Ian Lance Taylor writes:
>    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.

I'm happy to take the blame here. I know I'm pushing the envelope, and will
have to solve whatever problems I encounter in doing so.

I'm very thankful for Alan's patch which maintains the input order of sections
which were not named in the link description file. The ordering of unnamed
sections may be unspecified by the ld doco, but I think that maintaining the
input order in the output makes a lot of sense. It also solves my problem :-).

> 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.

Yes, these are the requirements exactly.

> 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).

Thanks for the suggestions; I'm not sure if I'm in a position to make such a
change to the kernel build process and inspire sufficient confidence in it to
get it accepted into the mainline, but I'm trying. I'll see what I can do.

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