Re: Binary compatibility loss regarding errno

[Jakub Jelinek <jakub at redhat dot com>]

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