This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] GDB's mdebug support vs. GCC 3.0
- To: Elena Zannoni <ezannoni at cygnus dot com>
- Subject: Re: [RFC] GDB's mdebug support vs. GCC 3.0
- From: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Date: Thu, 19 Jul 2001 16:08:58 -0700
- Cc: gdb-patches at sources dot redhat dot com
- References: <20010629123944.A3423@nevyn.them.org> <15191.24417.472551.89834@krustylu.cygnus.com>
On Thu, Jul 19, 2001 at 06:29:53PM -0400, Elena Zannoni wrote:
>
> Wow, what a messy control flow. Makes me dizzy. I am starting to
> understand this patch a bit. Just a few questions. Do you go through
> mipsread.c at all? If so, does mipscoff_new_init get called? If so,
> can you try to add the call to init_header_files in there instead?
The problem is that I don't go through mipsread at all. What we have
here is mdebug-in-ELF; elfmdebug_read_psymtab is where we enter mdebug
from.
> Next problem:
>
> Can you explain a bit more what happens there? I see that your new
> code in the if branch does the same things that process_one_symbol would do.
> . Change valu by the offset
> . call end_symtab
> . call end_stabs
>
> Are you saying that the symtab would be ended twice in that case? Once
> in process_one_symbol and once in psymtab_to_symtab_1?
> I think this the problem right?
> I am going to think some more.
That bit I'm not thrilled with. You're right; we used to not get the
final N_SO at all, and so process_one_symbol would not call end_symtab,
and we'd be safe when we called it ourselves after the loop. But GCC
3.0 does emit these N_SO's. We need to prevent process_one_symbol
(whose logic I'm not convinced we should be reusing on this path at
all, it's heinous!) from ending the symtab prematurely.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer