[rfa] eliminate some annoying mdebug-related symtab crashes

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

I'm really looking forward to getting away from mdebug and back to straight
ELF stabs, but I need mdebug for one last project.  This patch addresses two
of the crashes I've been having - properly, this time.

The init_header_files fix is almost trivial, although it might be preferable
to rename the functions now that I've had to make them non-static.  The list
was NULL, mdebugread's psymtab_to_symtab_1 was calling dbxread's
process_one_symbol which called add_new_header_file, and we crashed.  I'm
not sure if the extra:

+  stabsread_new_init ();
+  buildsym_new_init ();

is really necessary, since elfread_new_init() calls them, but analogy with
every other existing symbol reader suggests that it is correct, or at least
customary.


The init_psymbol_list is a little trickier.  Normally, both the global and
static symbol lists for an objfile are pre-allocated based on the expected
number of symbols.  mdebugread does not do that, which is, I think, fine. 
If global symbols are read but no static symbols are read, which has
happened to me in the startfiles several times, we should not be
re-initializing the list of symbols - there are psymtabs pointing in to what
we're freeing.  We only want to do that if neither global nor static symbols
have been read.


Are these OK to commit?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer
From fnasser@cygnus.com Mon Jul 09 15:13:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Testsuite addition for x86 linux GDB and SIGALRM fix
Date: Mon, 09 Jul 2001 15:13:00 -0000
Message-id: <3B4A2C7C.85C688C4@cygnus.com>
References: <200005192321.e4JNLEv13368@delius.kettenis.local> <3B3ABD6E.1040304@cygnus.com> <3B4A2056.4D58E307@cygnus.com> <20010709143406.A17003@nevyn.them.org>
X-SW-Source: 2001-07/msg00222.html
Content-length: 1657

Daniel Jacobowitz wrote:
> 
> On Mon, Jul 09, 2001 at 05:21:26PM -0400, Fernando Nasser wrote:
> > W.r.t. the tests for HP and IA64 I sincerely regret that we do not
> > have two commands: "finishi" and "finish".  The current behavior of
> > "finish" (stop at the assembler instruction after the call) is very
> > unsettling for someone who is doing source level debugging -- in this
> > case it should, after returning, single step until the end of the
> > sourceline where the call is ("if it is not at the beginning of a
> > source line after the return, single step to the end of it" would
> > do).
> 
> I think that the current behavior of finish, while awkward, is better
> than what you're suggesting here.  Suppose we have:
>   foo (bar (x));
> and we want to step in to foo.  There's two ways to do it; a breakpoint
> on foo, or step - finish - step. 

The breakpoint is the correct way.  The latter is an artifact.

> Stepping in to bar, typing finish,
> and ending up after the call to foo would be exceedingly non-intuitive.
> 

This is true. But a finish would not stop after the call to foo() in this case.  The stepping would be aborted as we entered foo() itself (note that I said "step", not "next").  The result is quite intuitive in this case and you just provided one good example of how we could use it -- one could go "finish"-ing until the desired function was entered (without the need to step again and without the weird thing of appearing to stop at the same line you were before).



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9