Re: [patch] Restore .gnu.linkonce.r. g++-3.4 linking

[Alan Modra <amodra at bigpond dot net dot au>]

On Thu, Oct 23, 2008 at 01:59:14AM +0200, Jan Kratochvil wrote:
> Hi,
> 
> the attached testcase reproduces a regression of ld on the output of g++-3.4:
> 
> binutils-2.15.92.0.2:
> `.gnu.linkonce.t.foo' referenced in section `.gnu.linkonce.r.foo' of
> /tmp/2j.o: defined in discarded section `.gnu.linkonce.t.foo' of /tmp/2j.o
> output produced  (.rela.gnu.linkonce.r.foo present with cleared relocations)
> 
> CVS HEAD:
> `.gnu.linkonce.t.foo' referenced in section `.gnu.linkonce.r.foo' of
> /tmp/2j.o: defined in discarded section `.gnu.linkonce.t.foo' of /tmp/2j.o
> no output

If you want output, you can use --noinhibit-exec.

> patched CVS HEAD:
> (no warnings)
> output produced (.rela.gnu.linkonce.r.foo present with cleared relocations)

ld should not silently produce what could be buggy output.  See PR 858
which resulted in references like the above becoming hard errors.

> /* g++-3.x specific - before COMDAT groups were supported.  .gnu.linkonce.r.*
>    is present only sometimes, depending on the compilation options.
>    .gnu.linkonce.r.* is like .rodata for its .gnu.linkonce.t.* so there is no
>    use for it if it did not exist in the file from which we chose
>    .gnu.linkonce.t.* as the one not being discarded.  We would also fail to
>    PRETEND the symbols as the other .gnu.linkonce.r.* section has different
>    size.  */
> 
> g++-3.x introduced .gnu.linkonce.r.* by:
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00653.html

So for 3.4.1 we ought to allow references from .rodata too?  Where do
we draw the line?

-- 
Alan Modra
Australia Development Lab, IBM