bug in gdb-5.0

[John Love-Jensen]

Dear gdb gurus,

I've run across a bug in gdb-5.0 (SunOS 5.8, gcc-2.95.2, -gstabs+ encoding)
while trying to debug a program's shared objects (.so).  The shared objects
are C++ code.  Also, the shared objects in question is a shared object of a
shared object of a shared object of the program in question.  All symbols
are fully loaded.  The "downstream" shared object (thrice removed from the
program) in question is quite large (~80 MiB, with ~21 MiB being symbol
information), if that's pertinent.

The problem:
    list 'Foo::Foo(void)'
cannot find the source file, and displays spurious information.  (Tab
completion works fine, though.)  The Foo class lives in a shared object
(.so).

Yet, this does NOT have the same problem:
    list 'Bar(void)'
which is located in the same source file / same shared object.  Jinkers!

Nor can I:
    break 'Foo::Foo(void)'
for (I assume) the same reason.  Also, I cannot effectively step into the
problem class methods.

I can neither get them to display via cooked C++ names, nor their mangled
names.

Running gdb on gdb shows that the hashing appears to be working correctly,
but resolving the pc and associating it back to the source file/line number
is wonky.

Thus, I think the bug in gdb is in the (symtab.c:463) find_pc_sect_psymbol
routine.  I tracked it down to that after carefully stepping through past
(symtab.c:3272).

I'll continue to debug gdb tomorrow (Monday) and send a follow up if I find
a remedy.

If you like, I can try to contrive a toy example that illustrates the
problem.  Assuming my brain hasn't implode by then.

Sincerely,

John Love-Jensen
Adobe Systems Incorporated