This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [patch] Restore .gnu.linkonce.r. g++-3.4 linking
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 24 Oct 2008 17:27:08 +1030
- Subject: Re: [patch] Restore .gnu.linkonce.r. g++-3.4 linking
- References: <20081022235914.GA26735@host0.dyn.jankratochvil.net>
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