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
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