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

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

On Fri, Jul 20, 2001 at 12:17:17AM -0400, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > 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.
> 
> Ahhh, OK. Ulgh. So you have an elf file, and you go through elfread.c.
> Let's see if I get the call stack right. Kind of hard to do w/o a
> stack trace.
> 
> syms_from_objfile calls
> elf_symfile_read calls
> elfmdebug_build_psymtabs calls
> mdebug_build_psymtabs calls
> parse_partial_symbols which sets up the symtab_read pointer to 
> mdebug_psymtab_to_symtab.
> 
> The function pointer is called by PSYMTAB_TO_SYMTAB
> then psymtab_to_symtab_1 is called,
> then process_one_symbol, 
> then add_new_header_file and there you get the problem with the headers.
> 
> Since process_one_symbol is called by other readers as well, and I
> assume the N_BINCL symbol is not new, there must be something upstream
> that gets screwed up.
> 
> I'll go back to something similar to my initial suggestion, then, can you
> try adding a call to init_header_files() from elf_new_init()?
> 
> This may fix your problem.

Actually, I fixed this problem in two places.  The other patch I sent
you a URL for (Subject: [rfa] eliminate some annoying mdebug-related
symtab crashes) calls init_header_files from mdebug_psymtab_to_symtab,
which was the best place I could find to do it from analogy with the
other readers.

> So if I read things correctly, the behavior of process_one_symbol is
> correct.  It figures that the N_SO marks the end of the file, and
> returns, w/o starting a new symtab. The problem is with the function
> that calls it. 
> 
> Could you do something like this instead? It is a little cleaner.

Won't work, I think.  If you do this:

> @@ -3368,9 +3388,13 @@
>  	    ;
>  	  else
>  	    complain (&stab_unknown_complaint, name);
> +	}
> +
> +      if (! last_symtab_ended)
> +	{
> +	  st = end_symtab (pst->texthigh, pst->objfile, SECT_OFF_TEXT (pst->objfile));
> +	  end_stabs ();
>  	}
> -      st = end_symtab (pst->texthigh, pst->objfile, SECT_OFF_TEXT (pst->objfile));
> -      end_stabs ();

Then st may or may not be initialized.  We'll die when we go to sort
the symtab a little further down.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer