[RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 3614 bytes --]

Hello,

After fixing the problem in mdebugread.c (see one of my recent patches),
GDB was no longer crashing, but some internal errors later appeared.
Something like this:

   warning: (Internal error: pc 0x3ff800203a8 in read in psymtab, but not in symtab.)

This would happen when trying to do a backtrace, for intance. These
warnings are really annoying, as they have a tendency to flood the
regular output...

I found that the address was a valid PC address for a function inside
one of the system libraries (eg libc or libpthread, for instance).  What
happened is that GDB was doing a symtab lookup for this address and did
not find any. It then did a psymtab lookup, and found one.  But then GDB
was surprised to find out that the psymtab was already read in, and
hence generated the warning. See find_pc_sect_symtab in symtab.c:

  | ALL_SYMTABS (objfile, s)
  |   {
  |     if (BLOCK_START (b) <= pc && BLOCK_END (b) > pc && [...])
  |       {
  |          [...]
  |          best_s = s;
  |       }
  |   }
  |
  | if (best_s != NULL)
  |   return best_s;
  |
  | ps = find_pc_sect_psymtab (pc, section);
  | if (ps)
  |   {
  |     if (ps->readin)
  |       warning ("Internal error: [...]");
  |     s = PSYMTAB_TO_SYMTAB (ps);
  |   }
  |
  | return s;

What really striked me when I started debugging this is that the
psymtab found by find_pc_sect_psymtab was completely incorrect.
At second thought, it should not have found any psymtab, since
the symbol in question did not come with any debugging info besides
the minimal symbol table.

So I looked at the textlow and texthigh values for the psymtab,
and was started by the texthigh value: 0xfffffffffffffffe, or
written differently: -2. A "maintenance print symbols" and "maintenance
print psymbols" confirmed that many symtabs had a suspisciouly high
texthigh value. These dumps also revealed that these entries contained
procedures with empty names and and address of 0xfffffffffffffffe.

Debugging a bit furter, I indeed found stProc symbol records whose value
are -2. I then looked up the Compaq documentation for the ECOFF format,
and it says p171 that (stProc, scInfo) entries represent "a procedure
without code, or a function prototype, or a function pointer". In that
case, the value field is respectively either -1, -2, or a non-negative
value.

I read a bit more about stProc and stStaticProc symbol records.
According to this documentation, only a very small subset of the
(storage type, storage class) couple is legal: 
  - stProc can only be associated with scNil, scText, scUndefined,
    and scInfo.
  - stStaticProc can only be associated with scText, scInit, and scFini.

It also says that only (stProc, scText) entries are "real" procedures
(all combinations of (stStaticProc, sc*) are "real" procedures).

I therefore made some modifications in mdebugread.c to ignore all
stProc entries when the storage class was not scText. This fixed
the warnings, and did not introduce any regressions.

But there is one flaw in my testing that I have to admit: we don't have
a C++ compiler on our Tru64 machine... I still suggest this fix for
inclusion in our sources, although I would understand that it be
rejected for lack of testing. I checked the output of the "maint print
symbols" and "maint print psymbols" commands, and did not find any
0xff[...]fe addresses anymore.

2003-01-03  J. Brobecker  <brobecker@gnat.com>

        * mdebugread.c (parse_symbol): Skip stProc entries which storage
        class is not scText. These do not define "real" procedures.
        (parse_partial_symbols): Likewise.

Ahem, ok to commit?
-- 
Joel

[-- Attachment #2: mdebugread.c.diff --]
[-- Type: text/plain, Size: 3828 bytes --]

Index: mdebugread.c
===================================================================
RCS file: /cvs/src/src/gdb/mdebugread.c,v
retrieving revision 1.35
diff -c -3 -p -r1.35 mdebugread.c
*** mdebugread.c	3 Jan 2003 15:34:59 -0000	1.35
--- mdebugread.c	3 Jan 2003 19:05:32 -0000
*************** parse_symbol (SYMR *sh, union aux_ext *a
*** 751,756 ****
--- 751,783 ----
  
      case stProc:		/* Procedure, usually goes into global block */
      case stStaticProc:		/* Static procedure, goes into current block */
+       /* Make sure this is a "real" procedure.  Otherwise, skip it.  */
+       if (sh->st == stProc && sh->sc != scText)
+         {
+           char *ext_tsym = ext_sh;
+           int keep_counting = 1;
+           SYMR tsym;
+ 
+           while (keep_counting)
+             {
+               ext_tsym += external_sym_size;
+               (*swap_sym_in) (cur_bfd, ext_tsym, &tsym);
+               count++;
+               switch (tsym.st)
+                 {
+                   case stParam:
+                     break;
+                   case stEnd:
+                     keep_counting = 0;
+                     break;
+                   default:
+                     complaint (&symfile_complaints,
+                                "unknown symbol type 0x%x", sh->st);
+                     break;
+                 }
+             }
+           break;
+         }
        s = new_symbol (name);
        SYMBOL_NAMESPACE (s) = VAR_NAMESPACE;
        SYMBOL_CLASS (s) = LOC_BLOCK;
*************** parse_partial_symbols (struct objfile *o
*** 3323,3328 ****
--- 3350,3383 ----
  		  /* FALLTHROUGH */
  
  		case stProc:
+ 		  /* Ignore all parameter symbol records.  */
+ 		  if (sh.index >= hdr->iauxMax)
+ 		    {
+ 		      /* Should not happen, but does when cross-compiling
+ 		         with the MIPS compiler.  FIXME -- pull later.  */
+ 		      index_complaint (name);
+ 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
+ 		    }
+ 		  else
+ 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
+ 					    (debug_info->external_aux
+ 					     + fh->iauxBase
+ 					     + sh.index));
+ 
+ 		  if (new_sdx <= cur_sdx)
+ 		    {
+ 		      /* This should not happen either... FIXME.  */
+ 		      complaint (&symfile_complaints,
+ 				 "bad proc end in aux found from symbol %s",
+ 				 name);
+ 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
+ 		    }
+ 
+                   /* Make sure that this stProc entry represents a "real"
+                      procedure.  If not, ignore it.  */
+                   if (sh.st == stProc && sh.sc != scText)
+                     goto skip;
+ 
  		  /* Usually there is a local and a global stProc symbol
  		     for a function. This means that the function name
  		     has already been entered into the mimimal symbol table
*************** parse_partial_symbols (struct objfile *o
*** 3345,3373 ****
  					 &objfile->static_psymbols,
  				    0, sh.value, psymtab_language, objfile);
  
- 		  /* Skip over procedure to next one. */
- 		  if (sh.index >= hdr->iauxMax)
- 		    {
- 		      /* Should not happen, but does when cross-compiling
- 		         with the MIPS compiler.  FIXME -- pull later.  */
- 		      index_complaint (name);
- 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
- 		    }
- 		  else
- 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
- 					    (debug_info->external_aux
- 					     + fh->iauxBase
- 					     + sh.index));
  		  procaddr = sh.value;
- 
- 		  if (new_sdx <= cur_sdx)
- 		    {
- 		      /* This should not happen either... FIXME.  */
- 		      complaint (&symfile_complaints,
- 				 "bad proc end in aux found from symbol %s",
- 				 name);
- 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
- 		    }
  
  		  cur_sdx = new_sdx;
  		  (*swap_sym_in) (cur_bfd,
--- 3400,3406 ----

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Daniel Jacobowitz]

On Fri, Jan 03, 2003 at 11:07:22PM +0400, Joel Brobecker wrote:
> Hello,
> 
> After fixing the problem in mdebugread.c (see one of my recent patches),
> GDB was no longer crashing, but some internal errors later appeared.
> Something like this:
> 
>    warning: (Internal error: pc 0x3ff800203a8 in read in psymtab, but not in symtab.)
> 
> This would happen when trying to do a backtrace, for intance. These
> warnings are really annoying, as they have a tendency to flood the
> regular output...
> 
> I found that the address was a valid PC address for a function inside
> one of the system libraries (eg libc or libpthread, for instance).  What
> happened is that GDB was doing a symtab lookup for this address and did
> not find any. It then did a psymtab lookup, and found one.  But then GDB
> was surprised to find out that the psymtab was already read in, and
> hence generated the warning. See find_pc_sect_symtab in symtab.c:
> 
>   | ALL_SYMTABS (objfile, s)
>   |   {
>   |     if (BLOCK_START (b) <= pc && BLOCK_END (b) > pc && [...])
>   |       {
>   |          [...]
>   |          best_s = s;
>   |       }
>   |   }
>   |
>   | if (best_s != NULL)
>   |   return best_s;
>   |
>   | ps = find_pc_sect_psymtab (pc, section);
>   | if (ps)
>   |   {
>   |     if (ps->readin)
>   |       warning ("Internal error: [...]");
>   |     s = PSYMTAB_TO_SYMTAB (ps);
>   |   }
>   |
>   | return s;
> 
> What really striked me when I started debugging this is that the
> psymtab found by find_pc_sect_psymtab was completely incorrect.
> At second thought, it should not have found any psymtab, since
> the symbol in question did not come with any debugging info besides
> the minimal symbol table.
> 
> So I looked at the textlow and texthigh values for the psymtab,
> and was started by the texthigh value: 0xfffffffffffffffe, or
> written differently: -2. A "maintenance print symbols" and "maintenance
> print psymbols" confirmed that many symtabs had a suspisciouly high
> texthigh value. These dumps also revealed that these entries contained
> procedures with empty names and and address of 0xfffffffffffffffe.
> 
> Debugging a bit furter, I indeed found stProc symbol records whose value
> are -2. I then looked up the Compaq documentation for the ECOFF format,
> and it says p171 that (stProc, scInfo) entries represent "a procedure
> without code, or a function prototype, or a function pointer". In that
> case, the value field is respectively either -1, -2, or a non-negative
> value.
> 
> I read a bit more about stProc and stStaticProc symbol records.
> According to this documentation, only a very small subset of the
> (storage type, storage class) couple is legal: 
>   - stProc can only be associated with scNil, scText, scUndefined,
>     and scInfo.
>   - stStaticProc can only be associated with scText, scInit, and scFini.
> 
> It also says that only (stProc, scText) entries are "real" procedures
> (all combinations of (stStaticProc, sc*) are "real" procedures).
> 
> I therefore made some modifications in mdebugread.c to ignore all
> stProc entries when the storage class was not scText. This fixed
> the warnings, and did not introduce any regressions.
> 
> But there is one flaw in my testing that I have to admit: we don't have
> a C++ compiler on our Tru64 machine... I still suggest this fix for
> inclusion in our sources, although I would understand that it be
> rejected for lack of testing. I checked the output of the "maint print
> symbols" and "maint print psymbols" commands, and did not find any
> 0xff[...]fe addresses anymore.
> 
> 2003-01-03  J. Brobecker  <brobecker@gnat.com>
> 
>         * mdebugread.c (parse_symbol): Skip stProc entries which storage
>         class is not scText. These do not define "real" procedures.
>         (parse_partial_symbols): Likewise.
> 
> Ahem, ok to commit?

Yes, I think so.  Meanwhile, I recommend:
 http://www.testdrive.hp.com/os/#tru64

I imagine they've got a C++ compiler available; yeah, it's a bit of a
nuisance to use their systems, but...


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

> > 2003-01-03  J. Brobecker  <brobecker@gnat.com>
> > 
> >         * mdebugread.c (parse_symbol): Skip stProc entries which storage
> >         class is not scText. These do not define "real" procedures.
> >         (parse_partial_symbols): Likewise.
> > 
> > Ahem, ok to commit?
> 
> Yes, I think so.  Meanwhile, I recommend:
>  http://www.testdrive.hp.com/os/#tru64
> 
> I imagine they've got a C++ compiler available; yeah, it's a bit of a
> nuisance to use their systems, but...

Ok, I have tested my change in one of their machines. Announcement: I
had to install gcc + dejagnu there, so if anyone is interested: I
installed GNAT 3.16w (2.8.1 based) + dejagnu in /house/brobecke/osf/bin.

My change did not show any regression in the C++ directory (did not run
the other tests), although as Daniel suggested, the results are rather
modest. For the record:

        # of expected passes            878
        # of unexpected failures        276
        # of expected failures          7
        # of unresolved testcases       33

Here is a new patch, with the comments a bit expanded, as recommended
by Elena.

Should I check this in?

Thanks,
-- 
Joel

[-- Attachment #2: mdebugread.c.diff --]
[-- Type: text/plain, Size: 4526 bytes --]

Index: mdebugread.c
===================================================================
RCS file: /cvs/src/src/gdb/mdebugread.c,v
retrieving revision 1.35
diff -c -3 -p -r1.35 mdebugread.c
*** mdebugread.c	3 Jan 2003 15:34:59 -0000	1.35
--- mdebugread.c	6 Jan 2003 11:26:38 -0000
*************** parse_symbol (SYMR *sh, union aux_ext *a
*** 751,756 ****
--- 751,788 ----
  
      case stProc:		/* Procedure, usually goes into global block */
      case stStaticProc:		/* Static procedure, goes into current block */
+       /* For stProc symbol records, we need to check the storage class
+          as well, as only (stProc, scText) entries represent "real"
+          procedures - See the Compaq document titled "Object File /
+          Symbol Table Format Specification" for more information.
+          If the storage class is not scText, we discard the whole block
+          of symbol records for this stProc.  */
+       if (sh->st == stProc && sh->sc != scText)
+         {
+           char *ext_tsym = ext_sh;
+           int keep_counting = 1;
+           SYMR tsym;
+ 
+           while (keep_counting)
+             {
+               ext_tsym += external_sym_size;
+               (*swap_sym_in) (cur_bfd, ext_tsym, &tsym);
+               count++;
+               switch (tsym.st)
+                 {
+                   case stParam:
+                     break;
+                   case stEnd:
+                     keep_counting = 0;
+                     break;
+                   default:
+                     complaint (&symfile_complaints,
+                                "unknown symbol type 0x%x", sh->st);
+                     break;
+                 }
+             }
+           break;
+         }
        s = new_symbol (name);
        SYMBOL_NAMESPACE (s) = VAR_NAMESPACE;
        SYMBOL_CLASS (s) = LOC_BLOCK;
*************** parse_partial_symbols (struct objfile *o
*** 3323,3328 ****
--- 3355,3393 ----
  		  /* FALLTHROUGH */
  
  		case stProc:
+ 		  /* Ignore all parameter symbol records.  */
+ 		  if (sh.index >= hdr->iauxMax)
+ 		    {
+ 		      /* Should not happen, but does when cross-compiling
+ 		         with the MIPS compiler.  FIXME -- pull later.  */
+ 		      index_complaint (name);
+ 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
+ 		    }
+ 		  else
+ 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
+ 					    (debug_info->external_aux
+ 					     + fh->iauxBase
+ 					     + sh.index));
+ 
+ 		  if (new_sdx <= cur_sdx)
+ 		    {
+ 		      /* This should not happen either... FIXME.  */
+ 		      complaint (&symfile_complaints,
+ 				 "bad proc end in aux found from symbol %s",
+ 				 name);
+ 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
+ 		    }
+ 
+                   /* For stProc symbol records, we need to check the
+                      storage class as well, as only (stProc, scText)
+                      entries represent "real" procedures - See the
+                      Compaq document titled "Object File / Symbol Table
+                      Format Specification" for more information.  If the
+                      storage class is not scText, we discard the whole
+                      block of symbol records for this stProc.  */
+                   if (sh.st == stProc && sh.sc != scText)
+                     goto skip;
+ 
  		  /* Usually there is a local and a global stProc symbol
  		     for a function. This means that the function name
  		     has already been entered into the mimimal symbol table
*************** parse_partial_symbols (struct objfile *o
*** 3345,3373 ****
  					 &objfile->static_psymbols,
  				    0, sh.value, psymtab_language, objfile);
  
- 		  /* Skip over procedure to next one. */
- 		  if (sh.index >= hdr->iauxMax)
- 		    {
- 		      /* Should not happen, but does when cross-compiling
- 		         with the MIPS compiler.  FIXME -- pull later.  */
- 		      index_complaint (name);
- 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
- 		    }
- 		  else
- 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
- 					    (debug_info->external_aux
- 					     + fh->iauxBase
- 					     + sh.index));
  		  procaddr = sh.value;
- 
- 		  if (new_sdx <= cur_sdx)
- 		    {
- 		      /* This should not happen either... FIXME.  */
- 		      complaint (&symfile_complaints,
- 				 "bad proc end in aux found from symbol %s",
- 				 name);
- 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
- 		    }
  
  		  cur_sdx = new_sdx;
  		  (*swap_sym_in) (cur_bfd,
--- 3410,3416 ----

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Elena Zannoni]

Yes, thanks.

Elena


Joel Brobecker writes:
 > > > 2003-01-03  J. Brobecker  <brobecker@gnat.com>
 > > > 
 > > >         * mdebugread.c (parse_symbol): Skip stProc entries which storage
 > > >         class is not scText. These do not define "real" procedures.
 > > >         (parse_partial_symbols): Likewise.
 > > > 
 > > > Ahem, ok to commit?
 > > 
 > > Yes, I think so.  Meanwhile, I recommend:
 > >  http://www.testdrive.hp.com/os/#tru64
 > > 
 > > I imagine they've got a C++ compiler available; yeah, it's a bit of a
 > > nuisance to use their systems, but...
 > 
 > Ok, I have tested my change in one of their machines. Announcement: I
 > had to install gcc + dejagnu there, so if anyone is interested: I
 > installed GNAT 3.16w (2.8.1 based) + dejagnu in /house/brobecke/osf/bin.
 > 
 > My change did not show any regression in the C++ directory (did not run
 > the other tests), although as Daniel suggested, the results are rather
 > modest. For the record:
 > 
 >         # of expected passes            878
 >         # of unexpected failures        276
 >         # of expected failures          7
 >         # of unresolved testcases       33
 > 
 > Here is a new patch, with the comments a bit expanded, as recommended
 > by Elena.
 > 
 > Should I check this in?
 > 
 > Thanks,
 > -- 
 > Joel
 > Index: mdebugread.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/mdebugread.c,v
 > retrieving revision 1.35
 > diff -c -3 -p -r1.35 mdebugread.c
 > *** mdebugread.c	3 Jan 2003 15:34:59 -0000	1.35
 > --- mdebugread.c	6 Jan 2003 11:26:38 -0000
 > *************** parse_symbol (SYMR *sh, union aux_ext *a
 > *** 751,756 ****
 > --- 751,788 ----
 >   
 >       case stProc:		/* Procedure, usually goes into global block */
 >       case stStaticProc:		/* Static procedure, goes into current block */
 > +       /* For stProc symbol records, we need to check the storage class
 > +          as well, as only (stProc, scText) entries represent "real"
 > +          procedures - See the Compaq document titled "Object File /
 > +          Symbol Table Format Specification" for more information.
 > +          If the storage class is not scText, we discard the whole block
 > +          of symbol records for this stProc.  */
 > +       if (sh->st == stProc && sh->sc != scText)
 > +         {
 > +           char *ext_tsym = ext_sh;
 > +           int keep_counting = 1;
 > +           SYMR tsym;
 > + 
 > +           while (keep_counting)
 > +             {
 > +               ext_tsym += external_sym_size;
 > +               (*swap_sym_in) (cur_bfd, ext_tsym, &tsym);
 > +               count++;
 > +               switch (tsym.st)
 > +                 {
 > +                   case stParam:
 > +                     break;
 > +                   case stEnd:
 > +                     keep_counting = 0;
 > +                     break;
 > +                   default:
 > +                     complaint (&symfile_complaints,
 > +                                "unknown symbol type 0x%x", sh->st);
 > +                     break;
 > +                 }
 > +             }
 > +           break;
 > +         }
 >         s = new_symbol (name);
 >         SYMBOL_NAMESPACE (s) = VAR_NAMESPACE;
 >         SYMBOL_CLASS (s) = LOC_BLOCK;
 > *************** parse_partial_symbols (struct objfile *o
 > *** 3323,3328 ****
 > --- 3355,3393 ----
 >   		  /* FALLTHROUGH */
 >   
 >   		case stProc:
 > + 		  /* Ignore all parameter symbol records.  */
 > + 		  if (sh.index >= hdr->iauxMax)
 > + 		    {
 > + 		      /* Should not happen, but does when cross-compiling
 > + 		         with the MIPS compiler.  FIXME -- pull later.  */
 > + 		      index_complaint (name);
 > + 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
 > + 		    }
 > + 		  else
 > + 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
 > + 					    (debug_info->external_aux
 > + 					     + fh->iauxBase
 > + 					     + sh.index));
 > + 
 > + 		  if (new_sdx <= cur_sdx)
 > + 		    {
 > + 		      /* This should not happen either... FIXME.  */
 > + 		      complaint (&symfile_complaints,
 > + 				 "bad proc end in aux found from symbol %s",
 > + 				 name);
 > + 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
 > + 		    }
 > + 
 > +                   /* For stProc symbol records, we need to check the
 > +                      storage class as well, as only (stProc, scText)
 > +                      entries represent "real" procedures - See the
 > +                      Compaq document titled "Object File / Symbol Table
 > +                      Format Specification" for more information.  If the
 > +                      storage class is not scText, we discard the whole
 > +                      block of symbol records for this stProc.  */
 > +                   if (sh.st == stProc && sh.sc != scText)
 > +                     goto skip;
 > + 
 >   		  /* Usually there is a local and a global stProc symbol
 >   		     for a function. This means that the function name
 >   		     has already been entered into the mimimal symbol table
 > *************** parse_partial_symbols (struct objfile *o
 > *** 3345,3373 ****
 >   					 &objfile->static_psymbols,
 >   				    0, sh.value, psymtab_language, objfile);
 >   
 > - 		  /* Skip over procedure to next one. */
 > - 		  if (sh.index >= hdr->iauxMax)
 > - 		    {
 > - 		      /* Should not happen, but does when cross-compiling
 > - 		         with the MIPS compiler.  FIXME -- pull later.  */
 > - 		      index_complaint (name);
 > - 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
 > - 		    }
 > - 		  else
 > - 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
 > - 					    (debug_info->external_aux
 > - 					     + fh->iauxBase
 > - 					     + sh.index));
 >   		  procaddr = sh.value;
 > - 
 > - 		  if (new_sdx <= cur_sdx)
 > - 		    {
 > - 		      /* This should not happen either... FIXME.  */
 > - 		      complaint (&symfile_complaints,
 > - 				 "bad proc end in aux found from symbol %s",
 > - 				 name);
 > - 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
 > - 		    }
 >   
 >   		  cur_sdx = new_sdx;
 >   		  (*swap_sym_in) (cur_bfd,
 > --- 3410,3416 ----

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Joel Brobecker]

> >  2003-01-03  J. Brobecker  <brobecker@gnat.com>
> >  
> >          * mdebugread.c (parse_symbol): Skip stProc entries which storage
> >          class is not scText. These do not define "real" procedures.
> >          (parse_partial_symbols): Likewise.
>
> Yes, thanks.

Thank you, checked in.

-- 
Joel

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Elena Zannoni]

Joel Brobecker writes:
 > Hello,
 > 
 > After fixing the problem in mdebugread.c (see one of my recent patches),
 > GDB was no longer crashing, but some internal errors later appeared.
 > Something like this:
 > 
 >    warning: (Internal error: pc 0x3ff800203a8 in read in psymtab, but not in symtab.)
 > 
 > This would happen when trying to do a backtrace, for intance. These
 > warnings are really annoying, as they have a tendency to flood the
 > regular output...
 > 

Yes, and they are silly too, because an internal error is not a warning...

 > I found that the address was a valid PC address for a function inside
 > one of the system libraries (eg libc or libpthread, for instance).  What
 > happened is that GDB was doing a symtab lookup for this address and did
 > not find any. It then did a psymtab lookup, and found one.  But then GDB
 > was surprised to find out that the psymtab was already read in, and
 > hence generated the warning. See find_pc_sect_symtab in symtab.c:
 > 
 >   | ALL_SYMTABS (objfile, s)
 >   |   {
 >   |     if (BLOCK_START (b) <= pc && BLOCK_END (b) > pc && [...])
 >   |       {
 >   |          [...]
 >   |          best_s = s;
 >   |       }
 >   |   }
 >   |
 >   | if (best_s != NULL)
 >   |   return best_s;
 >   |
 >   | ps = find_pc_sect_psymtab (pc, section);
 >   | if (ps)
 >   |   {
 >   |     if (ps->readin)
 >   |       warning ("Internal error: [...]");
 >   |     s = PSYMTAB_TO_SYMTAB (ps);
 >   |   }
 >   |
 >   | return s;
 > 
 > What really striked me when I started debugging this is that the
 > psymtab found by find_pc_sect_psymtab was completely incorrect.
 > At second thought, it should not have found any psymtab, since
 > the symbol in question did not come with any debugging info besides
 > the minimal symbol table.
 > 
 > So I looked at the textlow and texthigh values for the psymtab,
 > and was started by the texthigh value: 0xfffffffffffffffe, or
 > written differently: -2. A "maintenance print symbols" and "maintenance
 > print psymbols" confirmed that many symtabs had a suspisciouly high
 > texthigh value. These dumps also revealed that these entries contained
 > procedures with empty names and and address of 0xfffffffffffffffe.
 > 
 > Debugging a bit furter, I indeed found stProc symbol records whose value
 > are -2. I then looked up the Compaq documentation for the ECOFF format,
 > and it says p171 that (stProc, scInfo) entries represent "a procedure
 > without code, or a function prototype, or a function pointer". In that
 > case, the value field is respectively either -1, -2, or a non-negative
 > value.

I am drooling over this documentation you mention.... All I've ever
seen about mdebug is an old doco from Dave Anderson. Is the one you
are referring to publically available?

 > 
 > I read a bit more about stProc and stStaticProc symbol records.
 > According to this documentation, only a very small subset of the
 > (storage type, storage class) couple is legal: 
 >   - stProc can only be associated with scNil, scText, scUndefined,
 >     and scInfo.
 >   - stStaticProc can only be associated with scText, scInit, and scFini.
 > 
 > It also says that only (stProc, scText) entries are "real" procedures
 > (all combinations of (stStaticProc, sc*) are "real" procedures).
 > 
 > I therefore made some modifications in mdebugread.c to ignore all
 > stProc entries when the storage class was not scText. This fixed
 > the warnings, and did not introduce any regressions.
 > 
 > But there is one flaw in my testing that I have to admit: we don't have
 > a C++ compiler on our Tru64 machine... I still suggest this fix for
 > inclusion in our sources, although I would understand that it be
 > rejected for lack of testing. I checked the output of the "maint print
 > symbols" and "maint print psymbols" commands, and did not find any
 > 0xff[...]fe addresses anymore.
 > 
 > 2003-01-03  J. Brobecker  <brobecker@gnat.com>
 > 
 >         * mdebugread.c (parse_symbol): Skip stProc entries which storage
 >         class is not scText. These do not define "real" procedures.
 >         (parse_partial_symbols): Likewise.
 > 
 > Ahem, ok to commit?

I am not opposed to checking this in. Maybe Daniel J has some machines
available where he can do some further testing?  Only, I would like to
see some of the explanantions you wrote above, being included as
comments in the code.

Elena


 > -- 
 > Joel
 > Index: mdebugread.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/mdebugread.c,v
 > retrieving revision 1.35
 > diff -c -3 -p -r1.35 mdebugread.c
 > *** mdebugread.c	3 Jan 2003 15:34:59 -0000	1.35
 > --- mdebugread.c	3 Jan 2003 19:05:32 -0000
 > *************** parse_symbol (SYMR *sh, union aux_ext *a
 > *** 751,756 ****
 > --- 751,783 ----
 >   
 >       case stProc:		/* Procedure, usually goes into global block */
 >       case stStaticProc:		/* Static procedure, goes into current block */
 > +       /* Make sure this is a "real" procedure.  Otherwise, skip it.  */
 > +       if (sh->st == stProc && sh->sc != scText)
 > +         {
 > +           char *ext_tsym = ext_sh;
 > +           int keep_counting = 1;
 > +           SYMR tsym;
 > + 
 > +           while (keep_counting)
 > +             {
 > +               ext_tsym += external_sym_size;
 > +               (*swap_sym_in) (cur_bfd, ext_tsym, &tsym);
 > +               count++;
 > +               switch (tsym.st)
 > +                 {
 > +                   case stParam:
 > +                     break;
 > +                   case stEnd:
 > +                     keep_counting = 0;
 > +                     break;
 > +                   default:
 > +                     complaint (&symfile_complaints,
 > +                                "unknown symbol type 0x%x", sh->st);
 > +                     break;
 > +                 }
 > +             }
 > +           break;
 > +         }
 >         s = new_symbol (name);
 >         SYMBOL_NAMESPACE (s) = VAR_NAMESPACE;
 >         SYMBOL_CLASS (s) = LOC_BLOCK;
 > *************** parse_partial_symbols (struct objfile *o
 > *** 3323,3328 ****
 > --- 3350,3383 ----
 >   		  /* FALLTHROUGH */
 >   
 >   		case stProc:
 > + 		  /* Ignore all parameter symbol records.  */
 > + 		  if (sh.index >= hdr->iauxMax)
 > + 		    {
 > + 		      /* Should not happen, but does when cross-compiling
 > + 		         with the MIPS compiler.  FIXME -- pull later.  */
 > + 		      index_complaint (name);
 > + 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
 > + 		    }
 > + 		  else
 > + 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
 > + 					    (debug_info->external_aux
 > + 					     + fh->iauxBase
 > + 					     + sh.index));
 > + 
 > + 		  if (new_sdx <= cur_sdx)
 > + 		    {
 > + 		      /* This should not happen either... FIXME.  */
 > + 		      complaint (&symfile_complaints,
 > + 				 "bad proc end in aux found from symbol %s",
 > + 				 name);
 > + 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
 > + 		    }
 > + 
 > +                   /* Make sure that this stProc entry represents a "real"
 > +                      procedure.  If not, ignore it.  */
 > +                   if (sh.st == stProc && sh.sc != scText)
 > +                     goto skip;
 > + 
 >   		  /* Usually there is a local and a global stProc symbol
 >   		     for a function. This means that the function name
 >   		     has already been entered into the mimimal symbol table
 > *************** parse_partial_symbols (struct objfile *o
 > *** 3345,3373 ****
 >   					 &objfile->static_psymbols,
 >   				    0, sh.value, psymtab_language, objfile);
 >   
 > - 		  /* Skip over procedure to next one. */
 > - 		  if (sh.index >= hdr->iauxMax)
 > - 		    {
 > - 		      /* Should not happen, but does when cross-compiling
 > - 		         with the MIPS compiler.  FIXME -- pull later.  */
 > - 		      index_complaint (name);
 > - 		      new_sdx = cur_sdx + 1;	/* Don't skip at all */
 > - 		    }
 > - 		  else
 > - 		    new_sdx = AUX_GET_ISYM (fh->fBigendian,
 > - 					    (debug_info->external_aux
 > - 					     + fh->iauxBase
 > - 					     + sh.index));
 >   		  procaddr = sh.value;
 > - 
 > - 		  if (new_sdx <= cur_sdx)
 > - 		    {
 > - 		      /* This should not happen either... FIXME.  */
 > - 		      complaint (&symfile_complaints,
 > - 				 "bad proc end in aux found from symbol %s",
 > - 				 name);
 > - 		      new_sdx = cur_sdx + 1;	/* Don't skip backward */
 > - 		    }
 >   
 >   		  cur_sdx = new_sdx;
 >   		  (*swap_sym_in) (cur_bfd,
 > --- 3400,3406 ----

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Joel Brobecker]

> I am drooling over this documentation you mention.... All I've ever
> seen about mdebug is an old doco from Dave Anderson. Is the one you
> are referring to publically available?

Yes. I have a PDF document written by Compaq that I found on the web.
It's titled "Object file / Symbol Table Format Specification" (version
5.0 or higher, July 1998). I can't find this PDF anymore, but I found
a more recent version of the documentation in HTML format at:

http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/SUPPDOCS/OBJSPEC/NV50XXXX.HTM

> I am not opposed to checking this in. Maybe Daniel J has some machines
> available where he can do some further testing?  Only, I would like to
> see some of the explanantions you wrote above, being included as
> comments in the code.

Ok. Daniel suggested I use the machines from the HP testdrive program.
Hopefully, I'll have some time today and report back with some results
and more comments.

-- 
Joel

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Elena Zannoni]

Joel Brobecker writes:
 > > I am drooling over this documentation you mention.... All I've ever
 > > seen about mdebug is an old doco from Dave Anderson. Is the one you
 > > are referring to publically available?
 > 
 > Yes. I have a PDF document written by Compaq that I found on the web.
 > It's titled "Object file / Symbol Table Format Specification" (version
 > 5.0 or higher, July 1998). I can't find this PDF anymore, but I found
 > a more recent version of the documentation in HTML format at:
 > 
 > http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/SUPPDOCS/OBJSPEC/NV50XXXX.HTM
 > 


Thanks, that's useful. 


 > > I am not opposed to checking this in. Maybe Daniel J has some machines
 > > available where he can do some further testing?  Only, I would like to
 > > see some of the explanantions you wrote above, being included as
 > > comments in the code.
 > 
 > Ok. Daniel suggested I use the machines from the HP testdrive program.
 > Hopefully, I'll have some time today and report back with some results
 > and more comments.
 > 

ok



 > -- 
 > Joel

Re: [RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning

[Elena Zannoni]

Joel Brobecker writes:
 > > I am drooling over this documentation you mention.... All I've ever
 > > seen about mdebug is an old doco from Dave Anderson. Is the one you
 > > are referring to publically available?
 > 
 > Yes. I have a PDF document written by Compaq that I found on the web.
 > It's titled "Object file / Symbol Table Format Specification" (version
 > 5.0 or higher, July 1998). I can't find this PDF anymore, but I found
 > a more recent version of the documentation in HTML format at:
 > 
 > http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_HTML/SUPPDOCS/OBJSPEC/NV50XXXX.HTM
 > 

Found a newer version also in PDF:
http://www.tru64unix.compaq.com/docs/pub_page/V51B_DOCS/PRG_DOCS.HTM

there is a link towards the bottom of the page.

We should add it to the gdb doc's page.

Elena