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

[Elena Zannoni <ezannoni at cygnus dot com>]

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 ();