Internal error in GDB

Internal error in GDB

[Steven Johnson]

Im getting the error:

Internal error: pc 0x0 in read in psymtab, but not in symtab.

from a very recent CVS build of GDB (As of 11th November).

It happens when I set breakpoints in an assembler file, that has been 
assembled through GCC, using the C Preprocessor (.S file, not .s file).

It does nothing wrong, except pop up all the time and hence interfere 
with debugging significantly. (Im using insight and have to keep 
pressing OK to continue).

I searched the code and it seems to be coming from 
symtab.c:find_pc_sect_symtab (last if in the function)

The comment in the code indicates that this error may want to stop GDB 
cold. Thankfully it isn't, cause I seem to be getting it in error.

Also, the code here seems to be wrong, it prints the error, and then 
proceeds to look it up anyway. As in:

if (ps->readin)
   warning("Internal error: pc 0x%s in read in psymtab, but not in 
symtab.",paddr_nz(pc));

s = PSYMTAB_TO_SYMTAB(s)

I would have expected, from the error, it not to try and 
PSYMTAB_TO_SYMTAB, as it is saying it isn't in the SYMTAB. as in:

if (ps->readin)
   warning("Internal error: pc 0x%s in read in psymtab, but not in 
symtab.",paddr_nz(pc));
else
   s = PSYMTAB_TO_SYMTAB(s)

Anyway, what is going on here?  What do i need to do to my assembler 
file to prevent this warning?

Regards,
Steven Johnson

Re: Internal error in GDB

[Daniel Jacobowitz]

On Thu, Nov 14, 2002 at 05:34:05PM +1000, Steven Johnson wrote:
> Im getting the error:
> 
> Internal error: pc 0x0 in read in psymtab, but not in symtab.
> 
> from a very recent CVS build of GDB (As of 11th November).
> 
> It happens when I set breakpoints in an assembler file, that has been 
> assembled through GCC, using the C Preprocessor (.S file, not .s file).
> 
> It does nothing wrong, except pop up all the time and hence interfere 
> with debugging significantly. (Im using insight and have to keep 
> pressing OK to continue).
> 
> I searched the code and it seems to be coming from 
> symtab.c:find_pc_sect_symtab (last if in the function)
> 
> The comment in the code indicates that this error may want to stop GDB 
> cold. Thankfully it isn't, cause I seem to be getting it in error.
> 
> Also, the code here seems to be wrong, it prints the error, and then 
> proceeds to look it up anyway. As in:
> 
> if (ps->readin)
>   warning("Internal error: pc 0x%s in read in psymtab, but not in 
> symtab.",paddr_nz(pc));
> 
> s = PSYMTAB_TO_SYMTAB(s)
> 
> I would have expected, from the error, it not to try and 
> PSYMTAB_TO_SYMTAB, as it is saying it isn't in the SYMTAB. as in:
> 
> if (ps->readin)
>   warning("Internal error: pc 0x%s in read in psymtab, but not in 
> symtab.",paddr_nz(pc));
> else
>   s = PSYMTAB_TO_SYMTAB(s)
> 
> Anyway, what is going on here?  What do i need to do to my assembler 
> file to prevent this warning?

Do you have an assembler file you can post that triggers the warning? 
I'd like to see it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Internal error in GDB

[Daniel Jacobowitz]

On Thu, Nov 14, 2002 at 10:15:28AM -0500, Daniel Jacobowitz wrote:
> On Thu, Nov 14, 2002 at 05:34:05PM +1000, Steven Johnson wrote:
> > Im getting the error:
> > 
> > Internal error: pc 0x0 in read in psymtab, but not in symtab.
> > 
> > from a very recent CVS build of GDB (As of 11th November).
> > 
> > It happens when I set breakpoints in an assembler file, that has been 
> > assembled through GCC, using the C Preprocessor (.S file, not .s file).
> > 
> > It does nothing wrong, except pop up all the time and hence interfere 
> > with debugging significantly. (Im using insight and have to keep 
> > pressing OK to continue).
> > 
> > I searched the code and it seems to be coming from 
> > symtab.c:find_pc_sect_symtab (last if in the function)

Jim, I need your opinion on this... here's the problem.

2092      /* When using the GNU linker, .gnu.linkonce. sections are used to
2093         eliminate duplicate copies of functions and vtables and such.
2094         The linker will arbitrarily choose one and discard the others.
2095         The AT_*_pc values for such functions refer to local labels in
2096         these sections.  If the section from that file was discarded, the
2097         labels are not in the output, so the relocs get a value of 0.
2098         If this is a discarded function, mark the pc bounds as invalid,
2099         so that GDB will ignore it.  */
2100      if (low == 0 && (bfd_get_file_flags (objfile->obfd) & HAS_RELOC) == 0)
(top-gdb)
2101        return 0;
2102


In Steven's asm is a .vectors section which goes over the PPC hardware
interrupt vectors in RAM - that's actually at VMA 0.  Oops.

Since LD still doesn't edit DWARF-2 sections when discarding, and won't
for the forseeable future (although it needs to eventually), we can't
just drop the check.  Any ideas on what to do?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Internal error in GDB

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:

> On Thu, Nov 14, 2002 at 10:15:28AM -0500, Daniel Jacobowitz wrote:
> > On Thu, Nov 14, 2002 at 05:34:05PM +1000, Steven Johnson wrote:
> > > Im getting the error:
> > > 
> > > Internal error: pc 0x0 in read in psymtab, but not in symtab.
> > > 
> > > from a very recent CVS build of GDB (As of 11th November).
> > > 
> > > It happens when I set breakpoints in an assembler file, that has been 
> > > assembled through GCC, using the C Preprocessor (.S file, not .s file).
> > > 
> > > It does nothing wrong, except pop up all the time and hence interfere 
> > > with debugging significantly. (Im using insight and have to keep 
> > > pressing OK to continue).
> > > 
> > > I searched the code and it seems to be coming from 
> > > symtab.c:find_pc_sect_symtab (last if in the function)
> 
> Jim, I need your opinion on this... here's the problem.
> 
> 2092      /* When using the GNU linker, .gnu.linkonce. sections are used to
> 2093         eliminate duplicate copies of functions and vtables and such.
> 2094         The linker will arbitrarily choose one and discard the others.
> 2095         The AT_*_pc values for such functions refer to local labels in
> 2096         these sections.  If the section from that file was discarded, the
> 2097         labels are not in the output, so the relocs get a value of 0.
> 2098         If this is a discarded function, mark the pc bounds as invalid,
> 2099         so that GDB will ignore it.  */
> 2100      if (low == 0 && (bfd_get_file_flags (objfile->obfd) & HAS_RELOC) == 0)
> (top-gdb)
> 2101        return 0;
> 2102
> 
> 
> In Steven's asm is a .vectors section which goes over the PPC hardware
> interrupt vectors in RAM - that's actually at VMA 0.  Oops.
> 
> Since LD still doesn't edit DWARF-2 sections when discarding, and won't
> for the forseeable future (although it needs to eventually), we can't
> just drop the check.  Any ideas on what to do?

Jeez.  You'd think we would have learned by now that people like to
put things at the top and bottom of the address space...

Would it work to check that both the high and low bounds are zero?
Obviously, that's not going to handle a zero-length section at address
zero, but it'd at least be better than what we have now.

Is there *no* other way to tell whether the debug info refers to a
discarded section?  Can we add logic to BFD to tell us about this?

Could we generate custom GNU Dwarf 2 information so as to allow GDB to
detect a removed section?  That is, if we *ask* the linker to tell us,
will it?  We could make all debug info in linkonce sections children
of new DW_TAG_GNU_linkonce dies, with magic attributes that let us
detect whether they've been discarded.

DWARF-2 + discarded link-once sections (was Re: Internal error in GDB)

[Daniel Jacobowitz]

On Wed, Nov 20, 2002 at 11:25:26PM -0500, Jim Blandy wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Thu, Nov 14, 2002 at 10:15:28AM -0500, Daniel Jacobowitz wrote:
> > > On Thu, Nov 14, 2002 at 05:34:05PM +1000, Steven Johnson wrote:
> > > > Im getting the error:
> > > > 
> > > > Internal error: pc 0x0 in read in psymtab, but not in symtab.
> > > > 
> > > > from a very recent CVS build of GDB (As of 11th November).
> > > > 
> > > > It happens when I set breakpoints in an assembler file, that has been 
> > > > assembled through GCC, using the C Preprocessor (.S file, not .s file).
> > > > 
> > > > It does nothing wrong, except pop up all the time and hence interfere 
> > > > with debugging significantly. (Im using insight and have to keep 
> > > > pressing OK to continue).
> > > > 
> > > > I searched the code and it seems to be coming from 
> > > > symtab.c:find_pc_sect_symtab (last if in the function)
> > 
> > Jim, I need your opinion on this... here's the problem.
> > 
> > 2092      /* When using the GNU linker, .gnu.linkonce. sections are used to
> > 2093         eliminate duplicate copies of functions and vtables and such.
> > 2094         The linker will arbitrarily choose one and discard the others.
> > 2095         The AT_*_pc values for such functions refer to local labels in
> > 2096         these sections.  If the section from that file was discarded, the
> > 2097         labels are not in the output, so the relocs get a value of 0.
> > 2098         If this is a discarded function, mark the pc bounds as invalid,
> > 2099         so that GDB will ignore it.  */
> > 2100      if (low == 0 && (bfd_get_file_flags (objfile->obfd) & HAS_RELOC) == 0)
> > (top-gdb)
> > 2101        return 0;
> > 2102
> > 
> > 
> > In Steven's asm is a .vectors section which goes over the PPC hardware
> > interrupt vectors in RAM - that's actually at VMA 0.  Oops.
> > 
> > Since LD still doesn't edit DWARF-2 sections when discarding, and won't
> > for the forseeable future (although it needs to eventually), we can't
> > just drop the check.  Any ideas on what to do?
> 
> Jeez.  You'd think we would have learned by now that people like to
> put things at the top and bottom of the address space...
> 
> Would it work to check that both the high and low bounds are zero?
> Obviously, that's not going to handle a zero-length section at address
> zero, but it'd at least be better than what we have now.

Nope.  The missing section base will be considered to be zero.  Thus
the size of the discarded section will be whatever it normally would
have been, at 0 and 0+size.  Isn't it gross?

> Is there *no* other way to tell whether the debug info refers to a
> discarded section?  Can we add logic to BFD to tell us about this?

There really isn't.  It would be nice to discard it at link time.  But
this is, well, really complicated.  In my inexpert opinion at least.
(This is a similar problem to coalesced symbols in Darwin, as I
understand it?)

Hmm, maybe it isn't as bad as all that for DWARF-2.  If we get a die
with low_pc and high_pc attributes referring to a discarded section, we
could discard the die and all its children.  But there might be
_references_ to that die somewhere... this requires general purpose
DWARF-2 editing that we don't really have yet.

I'm CC'ing this over to binutils, because Alan and/or Jakub would have
a much better feel for whether this is possible than I do.

> Could we generate custom GNU Dwarf 2 information so as to allow GDB to
> detect a removed section?  That is, if we *ask* the linker to tell us,
> will it?  We could make all debug info in linkonce sections children
> of new DW_TAG_GNU_linkonce dies, with magic attributes that let us
> detect whether they've been discarded.

This could work too but it would be nice to avoid it.  We were
discussing .debug_info.gnu.linkonce.* sections at one point; did we
abandon that idea because there were too many of them, or was there
some other problem?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: DWARF-2 + discarded link-once sections (was Re: Internal error in GDB)

[H. J. Lu]

On Wed, Nov 20, 2002 at 11:49:40PM -0500, Daniel Jacobowitz wrote:
> 
> This could work too but it would be nice to avoid it.  We were
> discussing .debug_info.gnu.linkonce.* sections at one point; did we
> abandon that idea because there were too many of them, or was there
> some other problem?

What we need is GRP_COMDAT.


H.J.

Re: DWARF-2 + discarded link-once sections (was Re: Internal error in GDB)

[Daniel Berlin]

> > Is there *no* other way to tell whether the debug info refers to a
> > discarded section?  Can we add logic to BFD to tell us about this?
> 
> There really isn't.  It would be nice to discard it at link time.  But
> this is, well, really complicated.

It's no so much complicated as it is a pain in the ass to implement (big 
difference. One could probably explain how to do it to a 12 year old. But 
then he'd not want to implement it either. :P) 
>   In my inexpert opinion at least. > (This is a similar problem to coalesced symbols in Darwin, as I
> understand it?)
> 
> Hmm, maybe it isn't as bad as all that for DWARF-2.  If we get a die
> with low_pc and high_pc attributes referring to a discarded section, we
> could discard the die and all its children.  But there might be
> _references_ to that die somewhere... this requires general purpose
> DWARF-2 editing that we don't really have yet.
It's not that hard to do, if you do it with a worklist rather than trying 
to fix it up in one or two or n fixed passes.
The general solution is like this:
While walking over dies:
	1. record what other dies they reference (convert to absolute 
offset from start of debug_info).  An inverted index mapping absolute 
offsets to dies that reference them is what we really want. Ignore all 
sibling links, it's quicker to just rewrite them all then fix them up.
	2. Every time we decide to remove a die, push everything currently 
in the inverted index for that die's offset onto the fixup worklist, and 
remove them from the inverted index. Mark the die as needing to be fixed 
up (seperately. I'm assuming it would take O(n) time to check whether it's 
on the worklist or not, which we want to avoid later on).

Determine the new offsets for all dies, regardless of whether they have 
references *inside* them needing to be fixed up. Store this in an index of 
some sort.

Lastly, while there are still things on the fixup worklist:
	1. Fix the die references we can. If there are dies it references 
that need to be fixed up themselves, put it back on the end of the 
worklist, if not, it's a done die.

At the end, rewrite the sibling links.

The worklist will terminate unless you have circular die references (which 
you shouldn't), since there must be some die on the list not pointing to 
dies needing to be fixed up.
Of course, it might be O(n^2) iterations, but you can avoid this through 
going through dies in topological sorted order, the same way you 
would do on a flowgraph.



> 
> I'm CC'ing this over to binutils, because Alan and/or Jakub would have
> a much better feel for whether this is possible than I do.
> 
> > Could we generate custom GNU Dwarf 2 information so as to allow GDB to
> > detect a removed section?  That is, if we *ask* the linker to tell us,
> > will it?  We could make all debug info in linkonce sections children
> > of new DW_TAG_GNU_linkonce dies, with magic attributes that let us
> > detect whether they've been discarded.
> 
> This could work too but it would be nice to avoid it. 
Not just nice. It should be that we shouldn't do it unless their is some 
*incredibly* compelling reason to do so.

Let's *please* avoid adding a kludge when we know a solution to the 
problem, it's a solution we want for other reasons as well, and is maybe 
3x the work you'll do anyway.
Think of the ramifications of doing a DW_TAG_GNU_linkonce.
You'd screw other linkers and debuggers that currently support linkonce.
Some will later copy the whole DW_TAG_linkonce, to boot.
So when we want to throw it out in 2 years when someone finally implements 
this the right way, we won't be able to because those others will scream 
bloody murder.
We'll then be stuck with this kludge for 5 years anyway because that's 
when the majority of people got around to upgrading to something that 
doesn't generate or use it.

Is it *really* worth it?

If nobody wants to implement dwarf2 editing, just do nothing, rather than 
implement a kludge that we'll be stuck with.  
 > We were
 > discussing .debug_info.gnu.linkonce.* sections at one point; did we
> abandon that idea because there were too many of them, or was there
> some other problem?
> 
>