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

[Daniel Jacobowitz <drow at mvista dot com>]

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