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 _______________________________________________ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb