Re: [RFC] GDB's mdebug support vs. GCC 3.0

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

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