handling unexpected debugging unformation

[Mark Kettenis <kettenis at wins dot uva dot nl>]

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