This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gc sections and .eh_frame
- From: Jim Blandy <jimb at redhat dot com>
- To: binutils at sources dot redhat dot com
- Date: Wed, 24 Aug 2005 17:04:48 -0700
- Subject: Re: gc sections and .eh_frame
- References: <42A5DE0C.9050108@eCosCentric.com><200506280940.28723.ebotcazou@adacore.com><20050628114133.GC8706@bubble.grove.modra.org><200506281357.59145.ebotcazou@adacore.com><20050629012401.GD8706@bubble.grove.modra.org><20050629135426.GD28975@bubble.grove.modra.org><20050726112947.GF13611@bubble.grove.modra.org>
Alan Modra <amodra@bigpond.net.au> writes:
> I've been playing with enabling gc-sections for shared libs, and hit
> a problem with the way .gcc_except_table is handled. We were keeping
> .gcc_except_table itself, but not sections referenced from there.
If I'm understanding the whole saga here correctly, then one way of
describing what makes section GC interact with exception tables so
oddly is that the relocs point backwards from the way they normally
do.
That is, normally, if the GC keeps some section A, and A has relocs
referring to (symbols defined in) some section B, then the GC should
also keep B. Conversely, if there are no kept sections with relocs
referring to B, then B should be dropped.
For exception handling tables, however, the relocs point in the
opposite direction: if the GC keeps some code section A, and some
exception table B has relocs referring to A, then the GC should also
keep B. Conversely, if there are no kept code sections that an
exception table B has relocs referring to, then B should be dropped.
Not that folks don't already know this; I just thought it was a
helpfully clear way to describe things.