From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Daniel Jacobowitz Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFC] GDB's mdebug support vs. GCC 3.0 Date: Thu, 19 Jul 2001 20:18:00 -0000 Message-id: <15191.45261.525551.710968@krustylu.cygnus.com> References: <20010629123944.A3423@nevyn.them.org> <15191.24417.472551.89834@krustylu.cygnus.com> <20010719160858.A30318@nevyn.them.org> X-SW-Source: 2001-07/msg00503.html 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. > > > 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. > 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. Elena if (type_code & N_STAB) { - process_one_symbol (type_code, 0, valu, name, - pst->section_offsets, pst->objfile); + /* If we found a trailing N_SO with no name, we record this here, so that the symtab will not be ended twice, once in process_one_symbol, and once after this loop. */ + if (type_code == N_SO + && last_source_file + && previous_stab_code != (unsigned char) N_SO + && *name == '\000') + last_symtab_ended = 1; + else + last_symtab_ended = 0; + + process_one_symbol (type_code, 0, valu, name, + pst->section_offsets, pst->objfile); } /* Similarly a hack. */ else if (name[0] == '#') @@ -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 ();