This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
handling unexpected debugging unformation
- To: gdb at sourceware dot cygnus dot com
- Subject: handling unexpected debugging unformation
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Fri, 2 Jun 2000 22:50:17 +0200
Struggling with the misconfigured GCC 2.95.2 used by FreeBSD/Alpha as
its system compiler revealed some weaknesses in GDB with respect to
unexpected debugging information. Some extra stabs present in the
stabs-in-ecoff .mdebug section of an Alpha ELF executable caused GDB
to crash.
The problematic stabs in question are:
* N_BINCL stabs: These cause add_new_header_files to be called, but
since init_header_files() hasn't been called for stabs-in-ecoff,
GDB tries to dereference a null pointer. There are several possible
solutions, and I'll need some help choosing between them :-). Hence
a few questions:
- Should N_BINCL stabs be supported in stabs-in-ecoff?
- Is it acceptable to export free_header_files() and
init_header_files() from dbxread.c?
- Shouldn't mdebugread.c:elfmdebug_build_psymtabs() call
stabsread_new_init() and buildsym_new_init()?
- What about mdebug_build_psymtabs()?
* An extra blank N_SO stab (emitted by GCC for normal stabs-in-ELF):
mdebugread.c:psymtab_to_symtab_1() iterates over all stabs symbols,
calling dbxread.c:process_one_symbol() for them. If
process_one_symbol() sees an N_SO stab it will call end_symtab() if
we've seen an N_SO before, and then calls start_symtab() if the N_SO
stab isn't blank.
After the iteration psymtab_to_symtab_1() also calls end_symtab()
and uses its return value. The problem is that the blank N_SO stab
already finishes creating the symbol table. The end_symtab() in
psymtab_to_symtab_1() tries to do that again, freeing already freed
memory blocks, which again crashed GDB.
(The extra blank N_SO stab in normal ELF objects seems never to be
passed to process_one_symbal()).
Is there a way we can make this a bit more robust? Would setting
subfiles to NULL in buildsymtab.c:end_symtab() be sufficient?
Mark