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

[Joel Brobecker <brobecker at gnat dot com>]

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: mdebugread.c.diff
Description: Text document