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

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

[Ron McCall]

Hi,

I've been using gdb-6.3.50.20051026 (powerpc-eabi
target, sparc-solaris2.9 host) and have been getting a
lot of internal error messages like in the subject
line above.  This often happens when disassembling
code, even code that is part of the executable, both
before and after loading the code.  Is this a known
problem?  Would a newer snapshot be better?

Thanks for the help!

Ron McCall

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

[Daniel Jacobowitz]

On Tue, Nov 08, 2005 at 07:07:52AM -0800, Ron McCall wrote:
> Hi,
> 
> I've been using gdb-6.3.50.20051026 (powerpc-eabi
> target, sparc-solaris2.9 host) and have been getting a
> lot of internal error messages like in the subject
> line above.  This often happens when disassembling
> code, even code that is part of the executable, both
> before and after loading the code.  Is this a known
> problem?  Would a newer snapshot be better?

What debugging format are you using - stabs or dwarf2?  I don't know
offhand what could be causing this, and it's unlikely that a newer
snapshot will make a difference - that's pretty current.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Ron McCall]

On Sun, Nov 13, 2005 at 12:39:04PM -0500, Daniel Jacobowitz wrote:
> What debugging format are you using - stabs or dwarf2?  I don't know
> offhand what could be causing this, and it's unlikely that a newer
> snapshot will make a difference - that's pretty current.

I think it is dwarf2 (there are no sections with "stab" in the name,
just using -g).  I am using gcc-4.0.2 (also happens with gcc-4.0.1) with
binutils 2.16.1 and newlib 1.13.0, all the latest (released) versions,
in case that matters at all.

By the way, I did try a newer snapshot but still got the same result, as
you suspected.  I ran the cross gdb under a native gdb to try to see
what was happening.  With a breakpoint on find_pc_sect_symtab() in
symtab.c and a single command input of "disas 0xd00 0xd04" there are
several calls to this function.  I can re-run the test to get specific
input values if that would help.  If I remember correctly, the call that
resulted in the warning message being printed had inputs of pc=0 and
section=0.

If I enter "disas main" instead, no warnings are printed.  There is a
symbol at 0xd00 named trace_exc and "disas trace_exc" also generates the
warnings.  Note that the trace exception handler is written in assembly
(GNU as) and normally resides in a custom section named "excvectbl".
However, I changed that to ".text" just to make sure it wasn't the
custom section that was causing grief and that didn't help.

Anything else I should look at?

Thanks!

Ron McCall

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

[Daniel Jacobowitz]

On Mon, Nov 14, 2005 at 08:07:16PM -0500, Ron McCall wrote:
> If I enter "disas main" instead, no warnings are printed.  There is a
> symbol at 0xd00 named trace_exc and "disas trace_exc" also generates the
> warnings.  Note that the trace exception handler is written in assembly
> (GNU as) and normally resides in a custom section named "excvectbl".
> However, I changed that to ".text" just to make sure it wasn't the
> custom section that was causing grief and that didn't help.
> 
> Anything else I should look at?

Then it's probably a result of having some code with no debug info. 
You may want to try producing a small test case, that you can post for
us to examine.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Ron McCall]

On Mon, Nov 14, 2005 at 09:08:56PM -0500, Daniel Jacobowitz wrote:
> Then it's probably a result of having some code with no debug info. 
> You may want to try producing a small test case, that you can post for
> us to examine.

I'm not sure if an example is still wanted after the whole address zero
revelation but just in case, I have it.  Looks like the list doesn't
like attachments (even small ones) so I have put the 21 KB tarball at:

http://rmccall.dyndns.org/gdb-warning.tar.bz2

In that tarball are three source files (all short) and their
corresponding object files, my Makefile, linker script and specs file
overrides, the final executable, linker map file and disassembly
listing, a short gdb init script and most importantly the gdb session
output (gdb.out).  I get the warning when disassembling addresses in
exception_vector_table.S and also when disassembling addresses in main.c
that contain calls to code in exception_vector_table.S.  Note that the
contents of exception_vector_table.S are located starting at address
zero.

Is there anything more I can do to help?

Thanks again!

Ron McCall

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

[Vladimir Prus]

Ron McCall wrote:

> By the way, I did try a newer snapshot but still got the same result, as
> you suspected.  I ran the cross gdb under a native gdb to try to see
> what was happening.  With a breakpoint on find_pc_sect_symtab() in
> symtab.c and a single command input of "disas 0xd00 0xd04" there are
> several calls to this function.  I can re-run the test to get specific
> input values if that would help.  If I remember correctly, the call that
> resulted in the warning message being printed had inputs of pc=0 and
> section=0.

pc=0? Hmm, does your application start at address zero?
I distinctly remember I had to patch my local gdb version because it did not
like sections starting at address zero.

Below is the patch I use. But I'm not sure it's the problem in your case:
the patch fixes the "pc = 0" problem both for partial symbol table
(psymtab), and complete symbol table (symtab). Without this patch I get
error even earlier.

- Volodya

Index: gdb/dwarf2read.c
===================================================================
--- gdb/dwarf2read.c    (revision 1679)
+++ gdb/dwarf2read.c    (revision 1680)
@@ -3164,8 +3203,13 @@
      labels are not in the output, so the relocs get a value of 0.
      If this is a discarded function, mark the pc bounds as invalid,
      so that GDB will ignore it.  */
+  /* VP: commented out of the same reason as in read_partial_die.
+     Damn the code duplication.
+     */
+  #if 0
   if (low == 0 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0)
     return 0;
+  #endif
 
   *lowpc = low;
   *highpc = high;
@@ -5423,10 +5467,15 @@
      labels are not in the output, so the relocs get a value of 0.
      If this is a discarded function, mark the pc bounds as invalid,
      so that GDB will ignore it.  */
+  /* VP: 2005/04/20: On NM, text segment starts at address 0, so disable 
+     the check for zero. */
   if (has_low_pc_attr && has_high_pc_attr
       && part_die->lowpc < part_die->highpc
+#if 0
       && (part_die->lowpc != 0
-         || (bfd_get_file_flags (abfd) & HAS_RELOC)))
+         || (bfd_get_file_flags (abfd) & HAS_RELOC))
+#endif
+      )
     part_die->has_pc_info = 1;
   return info_ptr;
 }

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

[Ron McCall]

Oops, I think I sent that last reply directly to you
rather than the list.  Sorry about that.  Let me try
again.

--- Vladimir Prus <ghost@cs.msu.su> wrote:
> pc=0? Hmm, does your application start at address
> zero?
> I distinctly remember I had to patch my local gdb
> version because it did not
> like sections starting at address zero.

Yes, my application does indeed start at address zero
(the RAM copy of the exception vector table followed
by the remaining code and then data).

> Below is the patch I use. But I'm not sure it's the
> problem in your case:
> the patch fixes the "pc = 0" problem both for
> partial symbol table
> (psymtab), and complete symbol table (symtab).
> Without this patch I get
> error even earlier.

I applied your patch to a pristine copy of gdb 6.3 and
rebuilt and sure enough, that makes the warning go
away!  Should this patch get into the "real" gdb
sources?

Thanks for the help!

Ron McCall

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

[Jim Blandy]

On 11/15/05, Ron McCall <ronald.mccall@snet.net> wrote:
> I applied your patch to a pristine copy of gdb 6.3 and
> rebuilt and sure enough, that makes the warning go
> away!  Should this patch get into the "real" gdb
> sources?

No; take a look at the comment above one of the sections commented out
by the patch:

  /* When using the GNU linker, .gnu.linkonce. sections are used to
     eliminate duplicate copies of functions and vtables and such.
     The linker will arbitrarily choose one and discard the others.
     The AT_*_pc values for such functions refer to local labels in
     these sections.  If the section from that file was discarded, the
     labels are not in the output, so the relocs get a value of 0.
     If this is a discarded function, mark the pc bounds as invalid,
     so that GDB will ignore it.  */

Fixing this entails some more reliable method of recognizing debug
info referring to functions or variables in deleted sections than what
we have now.  Perhaps one of our linker fanatics knows of the Right
Way?

One possibility might be to tighten up the heuristic.  Presumably, if
a function's low address is at zero because the function is really
located at the bottom of the address space, then its high address
won't be zero.  But if the function was deleted, both the high and low
PC will be zero.

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

[Daniel Jacobowitz]

On Tue, Nov 15, 2005 at 03:10:52PM -0800, Jim Blandy wrote:
> Fixing this entails some more reliable method of recognizing debug
> info referring to functions or variables in deleted sections than what
> we have now.  Perhaps one of our linker fanatics knows of the Right
> Way?

We would need to verify that the section was Actually Present In The
Binary somehow.  Maybe by its symbols, maybe not.

> One possibility might be to tighten up the heuristic.  Presumably, if
> a function's low address is at zero because the function is really
> located at the bottom of the address space, then its high address
> won't be zero.  But if the function was deleted, both the high and low
> PC will be zero.

No, that doesn't work.  The high address is probably
.gnu.linkonce.foo+0x104, which may show up as 0x104 depending on the
relocation format in use.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Jim Blandy]

On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> No, that doesn't work.  The high address is probably
> .gnu.linkonce.foo+0x104, which may show up as 0x104 depending on the
> relocation format in use.

Checking my understanding:

When we drop a linkonce section, we also drop all relocs referring to
symbols defined in that section, or the section's STT_SECTION symbol. 
(Or do we just make the relocs use STN_UNDEF as their symbol?)  If the
architecture uses RELA relocs, then there's probably a zero sitting in
the code itself, but if it uses REL, then the addend is in the code,
so we'll see it when we read the value in GDB.

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

[Daniel Jacobowitz]

On Tue, Nov 15, 2005 at 04:12:14PM -0800, Jim Blandy wrote:
> On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> > No, that doesn't work.  The high address is probably
> > .gnu.linkonce.foo+0x104, which may show up as 0x104 depending on the
> > relocation format in use.
> 
> Checking my understanding:
> 
> When we drop a linkonce section, we also drop all relocs referring to
> symbols defined in that section, or the section's STT_SECTION symbol. 
> (Or do we just make the relocs use STN_UNDEF as their symbol?)  If the

Neither, quite.  We specifically fail to resolve them because they are
in .debug_info; otherwise this would be a fatal error.

> architecture uses RELA relocs, then there's probably a zero sitting in
> the code itself, but if it uses REL, then the addend is in the code,
> so we'll see it when we read the value in GDB.

Yes, that's exactly what I meant.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Jim Blandy]

On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> > When we drop a linkonce section, we also drop all relocs referring to
> > symbols defined in that section, or the section's STT_SECTION symbol.
> > (Or do we just make the relocs use STN_UNDEF as their symbol?)  If the
>
> Neither, quite.  We specifically fail to resolve them because they are
> in .debug_info; otherwise this would be a fatal error.

Do we need some sort of annotation in the debug information itself,
indicating that it's referring to stuff that might go away?

Suppose we had a new reloc type, generic name
BFD_RELOC_SECTION_INCLUDED, whose symbol must be an STT_SECTION
symbol.  The reloc refers to a single byte which the linker should set
to one if the symbol's section is present in the resulting object, or
zero if it has been dropped.

Then the appropriate dies could have a DW_AT_GNU_section_included
attribute, DW_FORM_flag, whose operand had that reloc applied to it.

The compiler's chopping the program up into these sections; make it
responsible for telling us what debug info corresponds to what code.

Ideally, the debug info itself would just get edited, but I'm not sure
how we would go about that.

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

[Daniel Jacobowitz]

On Tue, Nov 15, 2005 at 05:33:28PM -0800, Jim Blandy wrote:
> On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> > > When we drop a linkonce section, we also drop all relocs referring to
> > > symbols defined in that section, or the section's STT_SECTION symbol.
> > > (Or do we just make the relocs use STN_UNDEF as their symbol?)  If the
> >
> > Neither, quite.  We specifically fail to resolve them because they are
> > in .debug_info; otherwise this would be a fatal error.
> 
> Do we need some sort of annotation in the debug information itself,
> indicating that it's referring to stuff that might go away?

Sourceware hiccuped my last copy.... I wrote:

If you're going to change the toolchain to solve this problem, this
isn't the way to do it.  Just put the .debug_info section in a COMDAT
group with the section to be discarded.  This should be a pretty
trivial change nowadays, since the linker has grown proper COMDAT
support.

Inter-compilation-unit references make this feasible.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Jim Blandy]

On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> If you're going to change the toolchain to solve this problem, this
> isn't the way to do it.  Just put the .debug_info section in a COMDAT
> group with the section to be discarded.  This should be a pretty
> trivial change nowadays, since the linker has grown proper COMDAT
> support.

Okay.  I was hoping to get an answer of the form "Don't bother .* COMDAT .*".

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

[Daniel Jacobowitz]

On Tue, Nov 15, 2005 at 06:54:12PM -0800, Jim Blandy wrote:
> On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> > If you're going to change the toolchain to solve this problem, this
> > isn't the way to do it.  Just put the .debug_info section in a COMDAT
> > group with the section to be discarded.  This should be a pretty
> > trivial change nowadays, since the linker has grown proper COMDAT
> > support.
> 
> Okay.  I was hoping to get an answer of the form "Don't bother .* COMDAT .*".

:-)

It's mostly a matter of (A) getting gcc to actually start using comdat
where available, there were some hiccups last time we tried, and (B)
teaching the dwarf writer how to partition debug info; no one really
loves that code...

-- 
Daniel Jacobowitz
CodeSourcery, LLC