This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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



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?
Like this:

Index: mipsread.c
===================================================================
RCS file: /cvs/src/src/gdb/mipsread.c,v
retrieving revision 1.9
diff -u -p -r1.9 mipsread.c
--- mipsread.c	2001/05/29 10:45:10	1.9
+++ mipsread.c	2001/07/19 20:49:45
@@ -68,6 +68,7 @@ mipscoff_new_init (struct objfile *ignor
   sigtramp_address = 0;
   stabsread_new_init ();
   buildsym_new_init ();
+  init_header_files ();
 }
 
 /* Initialize to read a symbol file (nothing to do).  */



Does this work? It's a guess. I cannot test the code, really.

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.

thanks
Elena



Daniel Jacobowitz writes:
 > The stabs support for mips-linux is now much more complete than it was; from
 > what I can see this is because we started using config/elfos.h in gcc.  Two
 > of the gems we get from this are EINCL/BINCL stabs, which as far as I can
 > see we did not before, and a trailing SO at the end of a file.
 > 
 > The way we call process_one_symbol in dbxread.c from psymtab_to_symtab_1 in
 > mdebugread.c is, to say the least, a little iffy.  We aren't doing the
 > initialization it expects.  This patch is a pair of bandaids, but I think
 > that they're about as correct bandaids as I can manage.  I spent a while
 > going through the stabs reader, trying to figure out how these things are
 > actually supposed to work, and couldn't.  With the patch, we no longer crash
 > every time we try to read in a symtab; one obvious NULL pointer dereference,
 > and then doubled calls to end_symtab.
 > 
 > -- 
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer
 > 
 > 2001-06-29  Daniel Jacobowitz  <drow@mvista.com>
 > 	* dbxread.c (add_this_object_header_file): Make sure the header file
 > 	list is allocated.
 > 	* mdebugread.c (psymtab_to_symtab_1): Handle N_SO stabs without
 > 	a name specially.
 > 
 > Index: dbxread.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/dbxread.c,v
 > retrieving revision 1.18
 > diff -u -r1.18 dbxread.c
 > --- dbxread.c	2001/04/27 00:19:09	1.18
 > +++ dbxread.c	2001/06/29 19:32:28
 > @@ -345,6 +345,8 @@
 >  static void
 >  add_this_object_header_file (int i)
 >  {
 > +  if (n_allocated_this_object_header_files == 0)
 > +      init_header_files ();
 >    if (n_this_object_header_files == n_allocated_this_object_header_files)
 >      {
 >        n_allocated_this_object_header_files *= 2;
 > Index: mdebugread.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/mdebugread.c,v
 > retrieving revision 1.13
 > diff -u -r1.13 mdebugread.c
 > --- mdebugread.c	2001/05/29 10:45:10	1.13
 > +++ mdebugread.c	2001/06/29 19:32:29
 > @@ -3210,10 +3210,11 @@
 >    void (*swap_sym_in) (bfd *, PTR, SYMR *);
 >    void (*swap_pdr_in) (bfd *, PTR, PDR *);
 >    int i;
 > -  struct symtab *st;
 > +  struct symtab *st = NULL;
 >    FDR *fh;
 >    struct linetable *lines;
 >    CORE_ADDR lowest_pdr_addr = 0;
 > +  int last_symtab_ended = 0;
 >  
 >    if (pst->readin)
 >      return;
 > @@ -3319,8 +3320,27 @@
 >  	         complaining about them.  */
 >  	      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, process it here
 > +		     instead of in process_one_symbol, so we can keep its symtab. */
 > +		  if (type_code == N_SO
 > +		      && last_source_file
 > +		      && previous_stab_code != (unsigned char) N_SO
 > +		      && *name == '\000')
 > +		    {
 > +		      valu += ANOFFSET (pst->section_offsets,
 > +					SECT_OFF_TEXT (pst->objfile));
 > +		      previous_stab_code = N_SO;
 > +		      st = end_symtab (valu, pst->objfile,
 > +				       SECT_OFF_TEXT (pst->objfile));
 > +		      end_stabs ();
 > +		      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 ();
 >  
 >        /* Sort the symbol table now, we are done adding symbols to it.
 >           We must do this before parse_procedure calls lookup_symbol.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]