Mystified by "Internal error: pc 0x89f21e10 read in psymtab, but not in symtab

[Earl Chew]

Daniel Jacobowitz wrote:
> What debug information is produced by your toolchain - mdebug, I bet.
> Mdebug support is a little on the rotting side because we don't have
> anyone interested/willing to maintain it; and mdebug is a mighty
> arcane format.

So, I roll up my sleeves and start debugging gdb. I believe
the compiler is producing stabs in elf. How can I check?

The target is VxWorks using remote serial protocol with
segment resolution using qOffset.

I put in a couple of printfs, and notice that the
block vectors have start > end. Oops.

I put another breakpoint in end_symtab, and notice that
it's being called from read_ofile_symtab in dbxread.c. At the
end of this function, there's a line that reads:

pst->symtab = end_symtab (text_offset + text_size, objfile,
SECT_OFF_TEXT (objfile));

Looking at end_symtab in buildsym.c, I see:

      /* Make a block for the local symbols within.  */
      finish_block (cstk->name, &local_symbols, cstk->old_blocks,
                    cstk->start_addr, end_addr, objfile);

Printing cstk->start_addr, I see that this is the succesfully
relocated address (somewhere at 0x8fxxxxxx), but end_addr is
a small number --- obviously not relocated.

Patching dbxread.c

pst->symtab = end_symtab (text_offset +
                          text_size   +
         section_offsets->offsets[SECT_OFF_TEXT (objfile)],
         objfile, SECT_OFF_TEXT (objfile));

cures the problem.

But I'm not sure if this patch should be applied to
end_symtab() instead. I looked and end_symtab() is called from
many places, and I don't have enough information to decide
if they're right/wrong in the manner of dbxread.c.

Earl