This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Binary compatibility loss regarding errno
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Sat, 28 Dec 2002 23:48:42 +0100
- Subject: Re: Binary compatibility loss regarding errno
- References: <20021227133903.A5805@lucon.org> <200212272147.gBRLljq25869@magilla.sf.frob.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Dec 27, 2002 at 01:47:45PM -0800, Roland McGrath wrote:
Content-Description: message body text
> > On Fri, Dec 27, 2002 at 01:09:48PM -0800, Roland McGrath wrote:
> > > I consider this an ld bug. It's invalid to produce other than an
> > > R_386_GLOB_DAT reloc for a data object that is exported at runtime.
> >
> > If you have a small testcase, I will take a look.
>
> $ gcc -shared -o loser.so loser.c -Wl,--version-script=loser.v
> $ readelf -r loser.so
>
> Note no reloc using the symbol `x'.
>
Content-Description: C source file for ld bug test case
> int x;
> asm(".symver x,x@VERS_1");
> int foo() { return x; }
I think what should work is
int y;
asm(".symver y,x@VERS_1");
int foo() { return x; }
(have R_386_32 relocation against x@VERS_1 and x@VERS_1 exported
from the library). I'll work on this.
But .symver x,x@VERS_1 is grey area, I believe it should not be
allowed (it is not for .symver x,x@@VERS_1 BTW).
If not anything else, it will complicate bfd, because now we need
two different x symbols, one forced local, so that we don't end up
with STB_GLOBAL x unversioned symbol, one not forced local which
will be used to resolve references to x (which ought to be come
x@VERS_1).
Jakub