From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: [rfa] eliminate some annoying mdebug-related symtab crashes Date: Mon, 09 Jul 2001 15:11:00 -0000 Message-id: <20010709151122.A18937@nevyn.them.org> X-SW-Source: 2001-07/msg00221.html 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 To: Daniel Jacobowitz 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