Relocation against discarded sections

[Kris Van Hees]

I have been looking at a similar problem, that according to a colleague is
most likely the culprit.  Apparently this is related to an old gcc bug that
used to have a workaround in ld (later removed from ld).  It might still be
popping up perhaps (or in my case, I'm dealing with a library that I cannot
recompile that has been compiled using an older gcc with the bug present).

The problem I am looking at has bugzilla entries for gcc and ld:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276
http://sources.redhat.com/bugzilla/show_bug.cgi?id=233

Any chance this might be the same problem?  I am currently working on a
solution, but it is not likely to be very pretty.  From what I can see,
gold already has some support for the behaviour of older gcc versions.
With some luck I can convince people that a fix for this might be worth
putting in also?  Interestingly, it's only recently that gold actually
started complaining about it (which I guess is a good thing - before it
was silently letting things through and I am not convinced it was not
corrupting things somewhere).

	Kris

On Wed, Dec 17, 2008 at 02:36:59PM -0800, Cary Coutant wrote:
> > I understand why some sections should be discarded, but why are there relocations against discarded sections at all?
> >
> > I'm
> > running into a case in a private port that indicates that the
> > relocation is in code referencing RTTI data when the data section has
> > been discarded because there's another such section.  FWIW, both the
> > code and data sections came from the same object in the STL.
> >
> > I'm wondering why the linker - if it's the culprit - didn't fix references to the section being discarded.
> 
> It sounds like the relocations in the code sections were referring to
> local symbols defined in the RTTI data sections. In that case, there's
> nothing the linker can do to fix it up. There are two ways to fix
> this: have the compiler put both code and data in the same COMDAT
> group, so that if one gets discarded, the other does too; or make the
> symbols in the RTTI data sections global. Presumably, the data section
> is being discarded because it's the same as one from another
> compilation unit; in that case, the linker will resolve the references
> to the symbols defined in the kept section.
> 
> With gcc, I expect to see relocations against discarded sections from
> debug sections, where it's too much trouble to split the debug info up
> and put it into the comdat group it belongs with.
> 
> -cary