wrong address resolved for "extern" dynamic symbol with version set

[Roland McGrath]

I'm using gdb 5.1 (actually Red Hat gdb-5.1-0.71) on x86 GNU/Linux (RH 7.1),
specifically Red Hat glibc-2.2.4-19.

Compile the following program with "cc -o loser loser.c".

        #include <malloc.h>

         __malloc_ptr_t my_morecore(ptrdiff_tsize)
        {
          abort();
        }

        main() {
          __morecore = my_morecore;
          return 0;
        }

Following is a transcript of a gdb session on the resultant binary.  The
first suspicious output is the $2 value.  Is the @@ version set magic ever
supposed to be in user output like that?  Maybe it is, but it's suspicious.
Next, the error from "p &__morecore" is questionable.  There is a symbol by
that name with a fixed address defined by the executable, even though it's
one of those funny symbols with an R_386_COPY reloc.  But the real problem
comes later, when the program is running and libc.so.6's symbols have been
loaded.  Then gdb claims to know about "__morecore", but it lies!  The $3
value gives the address in the libc.so.6 image that nothing in this program
will actually use.  That is not what "__morecore" resolves to in this program.

I tried a similar example using my own trivial shared object instead of
libc, and did not see the bug.  The salient difference I can see off hand
is that my test case did not use symbol versions, and libc does.  That,
coupled with the @@ nonsense in the $2 value below, makes me suspect that
the version sets are involved somehow in confusing GDB.


(gdb) disas main
Dump of assembler code for function main:
0x804849c <main>:       push   %ebp
0x804849d <main+1>:     mov    %esp,%ebp
0x804849f <main+3>:     movl   $0x8048490,0x8049600
0x80484a9 <main+13>:    mov    $0x0,%eax
0x80484ae <main+18>:    pop    %ebp
0x80484af <main+19>:    ret    
End of assembler dump.
(gdb) p/a 0x8048490
$1 = 0x8048490 <my_morecore>
(gdb) p/a 0x8049600
$2 = 0x8049600 <__morecore@@GLIBC_2.0>
(gdb) p &__morecore
No symbol "__morecore" in current context.
(gdb) b main
Breakpoint 1 at 0x804849f
(gdb) r
Starting program: /home/roland/loser 
Reading symbols from /lib/i686/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading in symbols for dl-debug.c... and rtld.c... and 
../sysdeps/generic/dl-cache.c... and dl-init.c... and dl-deps.c... and 
dl-load.c... and dl-lookup.c...done.

Breakpoint 1, 0x0804849f in main ()
(gdb) i share
From        To          Syms Read   Shared Object Library
0x4004c450  0x4014c410  Yes         /lib/i686/libc.so.6
0x40001e80  0x400130e0  Yes         /lib/ld-linux.so.2
(gdb) p &__morecore
Reading in symbols for malloc.c... and soinit.c... and iconv.c... and 
../sysdeps/generic/check_fds.c... and 
../sysdeps/unix/sysv/linux/init-first.c... and iconv_open.c... and 
../sysdeps/generic/libc-start.c... and localeconv.c... and setlocale.c... and 
version.c... and gconv_conf.c... and gconv_db.c... and gconv_open.c... and 
gconv.c... and iconv_close.c... and gconv_trans.c... and gconv_simple.c... and 
iofdopen.c... and filedoalloc.c... and lc-time.c... and duplocale.c... and 
mb_cur_max.c... and findlocale.c... and nl_langinfo.c... and 
../sysdeps/generic/abort.c... and ../sysdeps/generic/sigjmp.c... and 
../sysdeps/unix/sysv/linux/signal.c... and strfmon.c... and printf_fp.c... and 
strtof.c... and erand48_r.c... and ctype-info.c... and 
../sysdeps/ieee754/dbl-64/s_isinf.c... and ../sysdeps/generic/strtol.c... and 
_itoa.c... and ../sysdeps/generic/inlines.c... and assert.c... and 
canonicalize.c... and ../sysdeps/unix/sysv/linux/sigprocmask.c... and 
../sysdeps/posix/raise.c...done.
$3 = (void *(**)()) 0x401649e0
(gdb) p/a 0x401649e0
$4 = 0x401649e0 <__morecore>