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

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

[Earl Chew]

I just stabilised a mips-vxworks (ELF) cross-debugger using gdb-5.0, and
rolled forward to gdb-5.2.1. Gdb-5.0 seems to work ok. But
I amazed to see 5.2.1 issue thousands of:

warning: (Internal error: pc 0x89f21e10 in read in psymtab, but not
in symtab.)

messages. I look at 0x89f21e10 in the VxWorks shell, and it
says:

-> l 0x89f21e10
                testRanking(int,const char*)
0x89f21e10 ... etc ...

So this address contains the first instruction of a function.

Does anyone know why gdb is issuing this warning, and why 5.0 was
ok with it?

Earl

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

[Daniel Jacobowitz]

On Fri, Sep 13, 2002 at 02:42:14PM -0700, Earl Chew wrote:
> I just stabilised a mips-vxworks (ELF) cross-debugger using gdb-5.0, and
> rolled forward to gdb-5.2.1. Gdb-5.0 seems to work ok. But
> I amazed to see 5.2.1 issue thousands of:
> 
> warning: (Internal error: pc 0x89f21e10 in read in psymtab, but not
> in symtab.)
> 
> messages. I look at 0x89f21e10 in the VxWorks shell, and it
> says:
> 
> -> l 0x89f21e10
>                 testRanking(int,const char*)
> 0x89f21e10 ... etc ...
> 
> So this address contains the first instruction of a function.
> 
> Does anyone know why gdb is issuing this warning, and why 5.0 was
> ok with it?

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 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

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

[Daniel Jacobowitz]

On Fri, Sep 13, 2002 at 03:42:16PM -0700, Earl Chew wrote:
> 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?

What version compiler and assembler are you using?  And are they FSF or
WindRiver-supplied?

You should be using stabs-in-ELF, but it requires matching Binutils and
GCC.  For binutils, it's enough to see that you get a .stab and
.stabstr and no .mdebug.  For GCC it's harder.

> 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.

This sounds like your GCC and binutils are out of sync, in fact.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Earl Chew]

Daniel Jacobowitz wrote:
> What version compiler and assembler are you using?  And are they FSF
> or WindRiver-supplied?

FSF gcc 2.95.4 and binutils 2.11 (I think).

> > 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.
> > 
> 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).

Earl
-- 
> ---------------------------------------------------------------------+
> Earl Chew                              http://www.agilent.com        |
> Agilent Technologies                   mailto:earl_chew@agilent.com  |
> Advanced Networks Division             Tel:   +1 604 454 3411        |
> 2500-4710 Kingsway                     Fax:   +1 604 454 3401        |
> Burnaby BC V5H 4M2 Canada                                            |
> ---------------------------------------------------------------------+

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

[Daniel Jacobowitz]

On Fri, Sep 13, 2002 at 04:13:04PM -0700, Earl Chew wrote:
> Daniel Jacobowitz wrote:
> > What version compiler and assembler are you using?  And are they FSF
> > or WindRiver-supplied?
> 
> FSF gcc 2.95.4 and binutils 2.11 (I think).

With any patches?  And, did you check which of .mdebug/.stab you're
getting?

> > > 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.
> > > 
> > 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 Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Earl Chew]

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.

>>>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.

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

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

[Daniel Jacobowitz]

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

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

[Earl Chew]

Daniel Jacobowitz wrote:
> 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.

If this patch introduced textlow/texthigh, then I think there's
good reason to suspect that removing it will make this problem go away
since it's the loss of synchronisation between the cached versions
of textlow/texthigh and those in the struct psymtab that appears to
be the problem.

However, I'm not sure if undoing this patch is the way to go since
you're not sure what Jim was trying to accomplish. I don't know enough
at this point to decide.

> 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...

I'm not sure what you mean here.

For the moment, I'm going to try to resynchronise the cache values. The
code compiles, but I won't be able to try it until to tomorrow.

Earl

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

[H. J. Lu]

On Sun, Sep 15, 2002 at 12:03:06PM -0400, Daniel Jacobowitz wrote:
> 
> 
> 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.
> 
> 

That patch is broken. See

http://sources.redhat.com/ml/gdb/2002-03/msg00197.html
http://sources.redhat.com/ml/gdb/2002-03/msg00202.html

Unfortunately, no one seems to care.


H.J.

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

[Daniel Jacobowitz]

On Sun, Sep 15, 2002 at 01:39:38PM -0700, H. J. Lu wrote:
> On Sun, Sep 15, 2002 at 12:03:06PM -0400, Daniel Jacobowitz wrote:
> > 
> > 
> > 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.
> > 
> > 
> 
> That patch is broken. See
> 
> http://sources.redhat.com/ml/gdb/2002-03/msg00197.html
> http://sources.redhat.com/ml/gdb/2002-03/msg00202.html
> 
> Unfortunately, no one seems to care.

Earl,

That second message contains the patch you were describing, for all
intents and purposes.  Could you try it?

Jim,

Any comments on that patch or this problem?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Earl Chew]

H. J. Lu wrote:
> That patch is broken. See
> 
> http://sources.redhat.com/ml/gdb/2002-03/msg00197.html
> http://sources.redhat.com/ml/gdb/2002-03/msg00202.html
> 
> Unfortunately, no one seems to care.

I care, I care!

How eerie. I wrote a set of changes this morning, and now comparing
with your changes --- it's uncanny how close they are.

I enclose my patches below for you to peruse. I have some questions
regarding some minor differences:

a. I figured it was better in general to invoke the relocation function
    pointer with the section offset structure, and let each
    implementation figure out what relocations are required. I
    thought that some implementations (in the future) might cache
    things other than text locations (eg data locations).

b. In dbxread.c, I initialise the relocate_symtab pointer in
    start_psymtab _and_ end_psymtab (where the code loops and allocates
    new psymtabs and copies values across).

    Your patch doesn't initialise the function pointer here, and I
    believe that this will result in an uninitialised field.

Earl
-- 
--- ../../gdb-5.2.1-orig/gdb/dbxread.c	2002-04-04 13:33:50.000000000 -0800
+++ dbxread.c	2002-09-15 08:52:53.000000000 -0700
@@ -277,6 +277,9 @@

  static void read_ofile_symtab (struct partial_symtab *);

+static void dbx_relocate_psymtab (struct partial_symtab *,
+                                  struct section_offsets *delta);
+
  static void dbx_psymtab_to_symtab (struct partial_symtab *);

  static void dbx_psymtab_to_symtab_1 (struct partial_symtab *);
@@ -2193,6 +2196,7 @@
    TEXTHIGH (result) = result->texthigh;
    LDSYMOFF (result) = ldsymoff;
    result->read_symtab = dbx_psymtab_to_symtab;
+  result->relocate_symtab  = dbx_relocate_psymtab;
    SYMBOL_SIZE (result) = symbol_size;
    SYMBOL_OFFSET (result) = symbol_table_offset;
    STRING_OFFSET (result) = string_table_offset;
@@ -2351,6 +2355,7 @@
        subpst->readin = 0;
        subpst->symtab = 0;
        subpst->read_symtab = pst->read_symtab;
+      subpst->relocate_symtab = pst->relocate_symtab;
      }

    sort_pst_symbols (pst);
@@ -2436,6 +2441,15 @@
    pst->readin = 1;
  }

+/* Relocate the cached text offsets for this psymtab. */
+
+static void
+dbx_relocate_psymtab (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));
+}
+
  /* Read in all of the symbols for a given psymtab for real.
     Be verbose about it if the user wants that.  */


--- ../../gdb-5.2.1-orig/gdb/objfiles.c	2001-12-06 11:59:12.000000000 -0800
+++ objfiles.c	2002-09-15 09:01:35.000000000 -0700
@@ -603,6 +603,9 @@
      {
        p->textlow += ANOFFSET (delta, SECT_OFF_TEXT (objfile));
        p->texthigh += ANOFFSET (delta, SECT_OFF_TEXT (objfile));
+
+      if (p->relocate_symtab)
+        (*p->relocate_symtab) (p, delta);
      }
    }


--- ../../gdb-5.2.1-orig/gdb/symfile.c	2002-06-22 09:49:34.000000000 -0700
+++ symfile.c	2002-09-15 21:28:55.000000000 -0700
@@ -2338,6 +2338,7 @@
    psymtab->section_offsets = section_offsets;
    psymtab->textlow = textlow;
    psymtab->texthigh = psymtab->textlow;		/* default */
+  psymtab->relocate_symtab = 0;
    psymtab->globals_offset = global_syms - objfile->global_psymbols.list;
    psymtab->statics_offset = static_syms - objfile->static_psymbols.list;
    return (psymtab);

--- ../../gdb-5.2.1-orig/gdb/symtab.h	2002-06-28 15:05:48.000000000 -0700
+++ symtab.h	2002-09-15 09:00:32.000000000 -0700
@@ -1029,6 +1029,11 @@

      void (*read_symtab) (struct partial_symtab *);

+    /* Pointer to function which will relocate the symtab corresponding to
+       this psymtab. May be 0 if no relocations are required. */
+
+    void (*relocate_symtab) (struct partial_symtab *, struct 
section_offsets *);
+
      /* Information that lets read_symtab() locate the part of the 
symbol table
         that this psymtab corresponds to.  This information is private 
to the
         format-dependent symbol reading routines.  For further detail 
examine

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

[H. J. Lu]

On Sun, Sep 15, 2002 at 09:42:51PM -0700, Earl Chew wrote:
> H. J. Lu wrote:
> > That patch is broken. See
> > 
> > http://sources.redhat.com/ml/gdb/2002-03/msg00197.html
> > http://sources.redhat.com/ml/gdb/2002-03/msg00202.html
> > 
> > Unfortunately, no one seems to care.
> 
> I care, I care!
> 
> How eerie. I wrote a set of changes this morning, and now comparing
> with your changes --- it's uncanny how close they are.
> 
> I enclose my patches below for you to peruse. I have some questions
> regarding some minor differences:
> 
> a. I figured it was better in general to invoke the relocation function
>     pointer with the section offset structure, and let each
>     implementation figure out what relocations are required. I
>     thought that some implementations (in the future) might cache
>     things other than text locations (eg data locations).

I don't think it helps since objfile_relocate only does offset. If you
pass delta, it is no longer symmetric. You don't want to use the same
function to do more than one thing here. You can always change it
together when you modify objfile_relocate later.

> 
> b. In dbxread.c, I initialise the relocate_symtab pointer in
>     start_psymtab _and_ end_psymtab (where the code loops and allocates
>     new psymtabs and copies values across).
> 
>     Your patch doesn't initialise the function pointer here, and I
>     believe that this will result in an uninitialised field.

I might miss that one.


H.J.

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

[Jim Blandy]

Yes, it looks like my patch was broken.  The stupid thing is, I never
actually went on to do the rest of the work that patch was supposed to
prepare GDB for, so its effect has been entirely deleterious.  :(
H. J.'s trademark bitterness aside, I do care that my patch broke GDB.
I don't remember ever seeing his bug report and patch before; I must
have missed them.  I apologize for the trouble that has caused.

Since I don't have any plans to proceed with the work I sketched out
in:

http://sources.redhat.com/ml/gdb-patches/2001-10/msg00304.html

in the immediate future, it makes sense to me to simply revert my
patch.  If I start the work again, I can always re-submit the patch,
but with the problem H. J. and Earl found corrected.

Can anyone come up with a test for this that one could run on Linux
native?

"H. J. Lu" <hjl@lucon.org> writes:

> On Sun, Sep 15, 2002 at 09:42:51PM -0700, Earl Chew wrote:
> > H. J. Lu wrote:
> > > That patch is broken. See
> > > 
> > > http://sources.redhat.com/ml/gdb/2002-03/msg00197.html
> > > http://sources.redhat.com/ml/gdb/2002-03/msg00202.html
> > > 
> > > Unfortunately, no one seems to care.
> > 
> > I care, I care!
> > 
> > How eerie. I wrote a set of changes this morning, and now comparing
> > with your changes --- it's uncanny how close they are.
> > 
> > I enclose my patches below for you to peruse. I have some questions
> > regarding some minor differences:
> > 
> > a. I figured it was better in general to invoke the relocation function
> >     pointer with the section offset structure, and let each
> >     implementation figure out what relocations are required. I
> >     thought that some implementations (in the future) might cache
> >     things other than text locations (eg data locations).
> 
> I don't think it helps since objfile_relocate only does offset. If you
> pass delta, it is no longer symmetric. You don't want to use the same
> function to do more than one thing here. You can always change it
> together when you modify objfile_relocate later.
> 
> > 
> > b. In dbxread.c, I initialise the relocate_symtab pointer in
> >     start_psymtab _and_ end_psymtab (where the code loops and allocates
> >     new psymtabs and copies values across).
> > 
> >     Your patch doesn't initialise the function pointer here, and I
> >     believe that this will result in an uninitialised field.
> 
> I might miss that one.
> 
> 
> H.J.

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

[Earl Chew]

Jim Blandy wrote:
> Since I don't have any plans to proceed with the work I sketched out
> in:
> 
> http://sources.redhat.com/ml/gdb-patches/2001-10/msg00304.html
> 
> in the immediate future, it makes sense to me to simply revert my
> patch.  If I start the work again, I can always re-submit the patch,
> but with the problem H. J. and Earl found corrected.

Jim, I'm happy with this proposal.

> Can anyone come up with a test for this that one could run on Linux
> native?

Sorry, I can't help out in this department.

Earl
-- 
> ---------------------------------------------------------------------+
> Earl Chew                              http://www.agilent.com        |
> Agilent Technologies                   mailto:earl_chew@agilent.com  |
> Advanced Networks Division             Tel:   +1 604 454 3411        |
> 2500-4710 Kingsway                     Fax:   +1 604 454 3401        |
> Burnaby BC V5H 4M2 Canada                                            |
> ---------------------------------------------------------------------+