Re: [PATCH RFA] partial-stab.h patch amendment

[Kevin Buettner <kevinb at cygnus dot com>]

I recently committed the following changes:

> 	* dbxread.c (process_one_symbol): Don't use error result from
> 	find_stab_function_addr().
> 	* partial-stab.h (case 'F'): Likewise.
> 
> 	* partial-stab.h (case 'f'): Make SOFUN_ADDRESS_MAYBE_MISSING
> 	code match that used for case 'F'.  This fixes the divergence
> 	that was introduced by my 1999-09-14 changes to partial-stab.h.

Those of you who've been following this thread should also be aware of
some additional analysis from H.J. Lu:

    http://sources.redhat.com/ml/gdb/2001-09/msg00046.html

I have dumped GDB's minimal symbol table and the partial symbol table
and have found that __strtol_internal appears once in the minimal
symbol table:

[413] T 0x40062634 __strtol_internal section .text  frame-dwarf2.c

But it appears twice in the partial symbol table:

Partial symtab for source file eval.c (object 0x828cb74)

  Read from object file /lib/libdl.so.2 (0x8270ff8)
  Relocate symbols by 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x0, 0x4002d000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
  Symbols cover text addresses 0x4002eb20-0x4002f10a
  Depends on 2 other partial symtabs.
    0 0x8283714 dlopen.c
    1 0x82844b8 dlerror.c
  Global partial symbols:
    `__strtol_internal', function, 0x4002d000
...

Partial symtab for source file ../sysdeps/generic/strtol.c (object 0x837860c)

  Read from object file /lib/i686/libc.so.6 (0x828d130)
  Full symtab was read (at 0x852f800 by function at 0x80f805c)
  Relocate symbols by 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x0, 0x40031000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
  Symbols cover text addresses 0x40062630-0x40062d3f
  Depends on 12 other partial symtabs.
    0 0x402fb3cc soinit.c
    1 0x83558d8 iconv_open.c
    2 0x82a08bc ../sysdeps/unix/sysv/linux/init-first.c
    3 0x8355284 ../sysdeps/generic/check_fds.c
    4 0x8357534 gconv.c
    5 0x8353024 ../sysdeps/generic/libc-start.c
    6 0x8362750 setlocale.c
    7 0x835be40 gconv_trans.c
    8 0x8357a18 gconv_db.c
    9 0x8364744 mb_cur_max.c
    10 0x83650bc lc-time.c
    11 0x835b220 gconv_simple.c
  Global partial symbols:
    `__strtol_internal', function, 0x40062634
...

The first of the psymtab entries for __strtol_internal is wrong.  When
I disassemble at the address in question, I see:

    (gdb) x/8i 0x4002d000
    0x4002d000:     jg     0x4002d047
    0x4002d002:     dec    %esp
    0x4002d003:     inc    %esi
    0x4002d004:     add    %eax,(%ecx)
    0x4002d006:     add    %eax,(%eax)
    0x4002d008:     add    %al,(%eax)
    0x4002d00a:     add    %al,(%eax)
    0x4002d00c:     add    %al,(%eax)

...which doesn't look like a function prologue to me.  (I've disassembled
the second one and it *does* look like a function prologue.)

So, how did this happen?

If you read H.J.'s message, you'll see that __strtol_internal appears
in libdl.so.2 as a weak undefined symbol.  It got that way presumably
through a bug somewhere else in the toolchain (linker perhaps?) which
converted it from a weak defined symbol to a weak undefined symbol.
Yet, in the process, the stabs entries related to this symbol weren't
removed.  Thus we end up having stabs entries which describe an
undefined symbol.

Prior to my patch, when gdb read such an entry (N_FUN, descriptor 'F',
with zero value), it would (assuming that the SOFUN_ADDRESS_MAYBE_MISSING
code is enabled):

    1) Notice that the value is zero.

    2) Due to the zero value, it would attempt to look up the value
       using the minimal symbols.

    3) Set pst->textlow to this value if it hadn't already been set.

For the particular case involving __strtol_internal, this symbol
appeared first and that caused the symbol's value to be set to
zero AND it caused pst->textlow to also be set to zero.  (It was this
last bit which caused disasterous consequences when looking up other
symbols.)

Now, with my patch applied, gdb no longer attempts to use a zero
value from the result of looking up the minimal symbol since this
(usually) represents an error condition.  Instead, the original
value is used which will be zero plus the offset of the .text
section.  This at least causes pst->textlow to be set correctly -
or at least closer to where it ought to be.

Either with or without my recent patch, a symbol ends up getting
defined which shouldn't be.  I'm not sure that this is of any great
concern because GDB gets its symbol information from several sources
and if one of these sources is inconsistent with another, it is not
unreasonable to expect GDB to become somewhat confused.  Also, it does
seem reasonable to expect there to be times when a symbol will be
defined by the debug info, but not by the linkage info.  So, it doesn't
seem like a good idea to refuse to add symbols to the partial symbol
table just because they don't exist in the minimal symbol table.

I don't really expect any comments on this message, but I wanted
write down what I know of the matter before moving on to something
else...

Kevin