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

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Sep 15, 2002 at 08:43:41AM -0700, Earl Chew wrote:
> Daniel Jacobowitz wrote:
> >With any patches?  And, did you check which of .mdebug/.stab you're
> >getting?
> 
> Some patches for VxWorks compatibility, and yes, it's using .stabs.

OK.  You're probably fine on this front; you might want to make sure
that .stabn directives end with something like "$LM1-main" [stabs
style] rather than "$LM1" [mdebug style] but I don't expect that to be
the problem.

> >>>This sounds like your GCC and binutils are out of sync, in fact.
> >>
> >>I'm pretty sure there's something wrong with gdb in this regard
> >>because end_symtab is being called with cstk->start_addr
> >>(succesfully relocated) and end_addr (not relocated).
> >
> >
> >One difference between stabs-in-mdebug and stabs-in-elf is whether line
> >and other addresses are relative to the beginning of the function or
> >absolute.  A mismatch causes this symptom.  If you're getting
> >stabs-in-ELF, I believe GCC 2.95 is not prepared for that.
> 
> Daniel, I can now see why you are suspicious about my previous attempt
> at a fix. Thinking about the problem some more, I see that if my
> attempted patch were really the proper fix, this problem should manifest
> itself in all sites running gdb --- and clearly it doesn't.
> 
> So I must be on the right track, but clearly, the patch isn't resolving
> the core of the problem.
> 
> I'm running gdb like this:
> 
>     vxgdb> file c:/foo.dbg
>     vxgdb> target remote 10.0.0.2:987
> 
> A consequence of the target command is that the remote is queried for
> qOffsets, and responds with the relocated addresses for .text, .data
> and .bss.
> 
> The result of this is that objfile_relocate in objfiles.c is called
> to relocate the symbols. I can see this walking the partial symbols
> using ALL_OBJFILE_PSYMTABS.
> 
> However, dbxread.c has private symbol information cached in
> read_symtab_private. The contents of this information is unknown
> to objfile_relocate, and hence it doesn't make any attempt to
> relocate it. I think the solution here is to provide another
> function pointer (eg relocate_symtab) to allow objfile_relocate
> to get this private information updated.


My first suspect:
2001-10-23  Jim Blandy  <jimb@redhat.com>

        Isolate STABS readers' use of the `textlow' and `texthigh' fields
        of `struct partial_symtab' to only a few locations.  This change
        is not supposed to affect the way the values are computed, only
        where they live.

        * dbxread.c (struct symloc): Add `textlow' and `texthigh' fields
        to the reader-specific structure.
        * mdebugread.c (struct symloc): Same.
        * dbxread.c (TEXTLOW, TEXTHIGH): New accessor macros.
        * mdebugread.c (TEXTLOW, TEXTHIGH): Same.
        * dbxread.c (dbx_symfile_read): After we've built all our partial
        symbol tables, set each partial symtab's `textlow' and `texthigh'
        fields from our reader-specific structure.
        * mdebugread.c (mdebug_build_psymtabs): Same.
        * dbxread.c (start_psymtab): Initialize the reader-specific
        structure's `textlow' and `texthigh' from the new psymtab's.
        * mdebugread.c (parse_partial_symbols, new_psymtab): Same.
        * dbxread.c (read_dbx_symtab, end_psymtab, read_ofile_symtab): Use
        the reader-specific `textlow' and `texthigh', not the generic
        psymtab fields.
        * mdebugread.c (parse_lines, parse_partial_symbols,
        psymtab_to_symtab_1): Same.
        * partial-stab.h: Same.

I no longer remember what Jim was trying to accomplish with this
change, but it sounds like you're on the right track.  You might want
to see if this patch is causing the problem.



If that doesn't help: there are other consumers of objfile_relocate. 
For instance, solib-svr4.c.  I use that code on a MIPS target without
seeing this problem.  Or at least I used to... not for terribly long,
as I went from mdebug to actually fixing DWARF-2 and using that.  Does
solib-svr4 manage to avoid this problem?

If so, rather than propogating this mess, is there some way you can use
the shared library code for this somehow?  A parallel, minimal "shared
library" implementation which gets relocation information via
qOffsets...

> 
> So, I think objfiles.c needs to be changed to:
> 
>   {
>     struct partial_symtab *p;
> 
>     ALL_OBJFILE_PSYMTABS (objfile, p)
>     {
>       p->textlow += ANOFFSET (delta, SECT_OFF_TEXT (objfile));
>       p->texthigh += ANOFFSET (delta, SECT_OFF_TEXT (objfile));
> 
>       p->relocate_symtab(p, delta);
>     }
>   }
> 
> And the implementation for dbxread.c should be:
> 
> static void dbx_relocate_symtab(
>     struct partial_symtab* pst,
>     struct section_offsets* delta)
> {
>     TEXTLOW(pst) += ANOFFSET (delta, SECT_OFF_TEXT (pst->objfile));
>     TEXTHIGH(pst) += ANOFFSET (delta, SECT_OFF_TEXT (pst->objfile));
> }
> 
> Corresponding implementations are required in dwarf2read.c, hpread.c,
> mdebugread.c, os9kread.c and xcoffread.c. Some of these do not
> cache offsets the way dbxread.c does, so the relocation function
> can be empty.
> 
> Earl
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer