[RFA] Fix a "pc ... in psymtab but not in symtab" internal error warning
Daniel Jacobowitz
drow@mvista.com
Fri Jan 3 19:19:00 GMT 2003
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
More information about the Gdb-patches
mailing list