This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Binary compatibility loss regarding errno
On Mon, Dec 30, 2002 at 11:10:07AM -0800, H. J. Lu wrote:
> On Sat, Dec 28, 2002 at 05:57:34PM -0500, Jakub Jelinek wrote:
> > On Sat, Dec 28, 2002 at 02:53:53PM -0800, Roland McGrath wrote:
> > > > (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).
> > >
> > > There are several places in glibc we would have to change in that case.
> > > It was always allowed before. It works in other cases, e.g. __ctype_b.
> >
> > I know that very well. But as I remember, __ctype_b etc. was done that way
> > exactly because .symver __old_ctype_b, __ctype_b@GLIBC_2.0 + access to
> > __ctype_b in the same DSO/binary was borken, so
> > .symver __ctype_b, __ctype_b@GLIBC_2.0 was used, as that seemed
> > to work. Apparently only partly.
>
> Do you have a testcase for that?
Of course:
cat > lib.c <<EOF
int y = 12;
asm (".symver y, x@VERS_1");
extern int x;
void foo (void)
{
x = 24;
}
EOF
cat > lib.map <<EOF
VERS_1 {
global: x; foo;
local: *;
};
EOF
gcc -shared -O2 -fpic -o lib.so lib.c -Wl,-version-script,lib.map
This is basically what you tried in your today's errno.c patch.
The purpose of the code is
a) to make x unavailable for newly linked programs
b) for already linked binaries which have R_*_COPY relocs against
x@VERS_1, modify the variable in binary's .dynbss, not actually
y in the shared library
What binutils ld does is:
0000173c 00001a06 R_386_GLOB_DAT 00000000 x
26: 00000000 0 NOTYPE GLOBAL DEFAULT UND x
27: 00001640 4 OBJECT GLOBAL DEFAULT 14 x@VERS_1
while the intended result is that the symbol at position 26
doesn't show up at all and the reloc is against x@VERS_1.
Now if you change the above testcase with perl -pi -e 's/ y/ x/g' lib.c
you end up with what glibc is doing ATM. This changes things to:
00001728 00000008 R_386_RELATIVE
26: 0000162c 4 OBJECT GLOBAL DEFAULT 14 x@VERS_1
ie. .dynsym is ok, while the relocation is relative, not absolute.
For the latter case, I think changing elf_link_assign_sym_version
if matched == TRUE, so that if h is a def or defweak symbol and
x@the_version has the same value/section (ie. if .symver x, x@the_version
was used), change x into indirect symbol might work.
Jakub