Re: Relocation against discarded sections

[Evandro Menezes <evandro at yahoo dot com>]

 Jan,

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.

Thanks.




________________________________
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Evandro Menezes <evandro@yahoo.com>
Cc: binutils@sourceware.org
Sent: Wednesday, December 17, 2008 2:49:22 PM
Subject: Re: Relocation against discarded sections

On Wed, 17 Dec 2008 21:16:17 +0100, Evandro Menezes wrote:
> There's code to handle relocations against symbols in discarded sections in
> elflink.c.  But firstly why do they happen at all?

Some sections may get discarded - for example inlined functions of C++ classes
"classA.h":
    class A
    { 
    public:
        A (int a) { f (); };
    };  
A::A() needs to be defined only once but such function is present in each .o
file.  Therefore during linking only one such instance is left and other
instances are discarded.

This is being currently done through COMDAT groups, it were .gnu.linkonce.*
sections before.

And some sections can be referencing these link-once sections, such as
.eh_frame containing exceptions unwinding information for these inlined
functions.  If the function itself is removed the entries for it in the
.eh_frame section are no longer needed.  Therefore these entries must be
safely nullified by removing the relocations _to_ the discarded section.


If anyone (Alan Modra?) would be so kind to approve my last version of:
Re: [patch] Restore .gnu.linkonce.r. g++-3.4 linking
http://sourceware.org/ml/binutils/2008-11/msg00195.html
followup on: http://sourceware.org/ml/binutils/2008-10/threads.html#00200


Thanks,
Jan