[patch] Restore .gnu.linkonce.r. g++-3.4 linking
Alan Modra
amodra@bigpond.net.au
Fri Oct 24 06:58:00 GMT 2008
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
More information about the Binutils
mailing list