[RFA:] test-case for relocs for linkonce-excluded sections don't become zero, causing g++ EH failure

[Hans-Peter Nilsson]

> Date: Sun, 30 Sep 2001 14:34:42 -0700
> From: Geoff Keating <geoffk@geoffk.org>

> > Date: Sat, 29 Sep 2001 19:57:37 +0930
> > From: Alan Modra <amodra@bigpond.net.au>

> > I'll take a look at it - we might be able to get rid of kept_section
> > as that was something I added to struct section when writing this
> > bit of code.
> 
> I would rather that people just spent their time on fixing gcc so that
> it does the right thing.

I'll try and elaborate on the way I see things, and why I think
just changing gcc is not a viable option, even though in a
perfect world (without releases?) it would be the right thing to
--at least also-- fix gcc.

We have a mismatch between what gcc expects and binutils
delivers in official versions.  GCC expects local symbols to
linkonce-excluded sections to become zero, and binutils resolves
them to the remaining linkonce section.

This mismatch goes back to the gcc-2.96 non-releases (AFAICT),
on to gcc-3.0, gcc-3.01 and will be in the upcoming gcc-3.02
(unless someone delivers a fix for it).  Regarding binutils,
this mismatch includes a version recommended for gcc-3.0.X
across many platforms: binutils-2.11.2 (well, I checked the 2.11
release branch, not the actual release).  So one or both has to
change.

We can change GCC, and there are at least two non-exclusive ways
to change it, not including forcing --enable-sjlj-exceptions:

1. Accept and handle that local symbols referring to
linkonce-excluded sections don't become zero, by e.g. walking
the FDE:s after sorting them, and neutralize duplicates;
pointing to the same pc but where the FDE is located at a higher
address.  The assumption would be that FDE:s at higher addresses
correspond to "excluded" functions.  That might not be a
completely safe assumption, but perhaps acceptable.  The
run-time overhead is unimportant; it could reasonably be O(N)
after a supposedly O(N*log(N)) sort, and we're on an exceptional
path anyway.

2. Make gcc use what is implemented in binutils regarding
grouping of FDE:s in separate linkonce sections, making sure the
section groups keep their relative positions (in each object
file, the CIE, then the FDE:s for each function).  I'm not
completely sure about what's in this functionality, but I
believe this requires a new binutils release anyway.  IIUC it's
not included in 2.11.X.  I guess it would be as non-standard as
GNU linkonce anyway, to assume that ordering of sections within
an object survive linking.

Binutils can be changed:

1. Return to the old behaviour and zero out symbols in
linkonce-excluded sections.  This is fixed on the trunk, but we
need a release to go with current and upcoming releases of gcc.

2. Implement SHF_GROUP/SHT_GROUP and make use of it in gcc (and
for gcc require the new binutils release).

3. Release (from trunk) binutils and make use of the section
ordering and linkonce-exclusion in gcc (and for gcc require the
new binutils release).

This is a matter of the most practical solution, since we have a
time constraint (the new gcc coming up, with months to the next
release) and combinations of the current official GCC and
binutils releases are broken wrt. exception handling.  Binutils
changes 2 and 3 are tied to matching changes in gcc, which isn't
good.  Also, gcc change 1 seems too intrusive this late in its
release process.  The simplest and IMHO best change is to make a
binutils release (change 1) that corresponds to old behaviour
and what gcc expects, and alert people in the gcc installation
instructions that the new binutils release is required.  I don't
see the other solutions happen, and if they do, we haven't done
much extra work - we have your (Geoff's) patch for binutils
2.11.X and the trunk is already fixed.  Whenever gcc is changed,
there should be no remaining references to linkonce-excluded
sections, so by then it wouldn't matter what value they get.
For compatibility perhaps, the old binutils behavior could in
future versions be restricted to sections having a
".gnu.linkonce" prefix.

> > Linkonce functionality is an extension
> > anyway.  Relocations against such sections doesn't *have* to
> > have the same semantics as "normal" sections.
> 
> I believe that linkonce sections are now standardized.

Do you mean SHF_GROUP/SHT_GROUP?  (Documented at
<URL: http://www.sco.com/developer/gabi/latest/ch4.sheader.html >,
found from the gcc readings page.)  That's not implemented in
binutils.  If that's not what you refer to, (and if you have
them), please provide pointers.

brgds, H-P