This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Mystified by "Internal error: pc 0x89f21e10 read in psymtab, but not in symtab
- From: Earl Chew <earl_chew at agilent dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 13 Sep 2002 15:42:16 -0700
- Subject: Re: Mystified by "Internal error: pc 0x89f21e10 read in psymtab, but not in symtab
- Organization: Agilent Technologies
- References: <3D825BB5.48CFAFAB@agilent.com> <20020913220110.GA22097@nevyn.them.org>
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