public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@red-bean.com>
To: Ron McCall <ronald.mccall@snet.net>
Cc: gdb@sources.redhat.com
Subject: Re: warning: (Internal error: pc 0xd00 in read in psymtab, but not in symtab.)
Date: Tue, 15 Nov 2005 23:10:00 -0000	[thread overview]
Message-ID: <8f2776cb0511151510p1d7fe81dl7aa7a6b439b4622@mail.gmail.com> (raw)
In-Reply-To: <20051115204629.32845.qmail@web81206.mail.mud.yahoo.com>

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.

  reply	other threads:[~2005-11-15 23:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-08 15:07 Ron McCall
2005-11-13 17:39 ` Daniel Jacobowitz
2005-11-15  1:07   ` Ron McCall
2005-11-15  2:09     ` Daniel Jacobowitz
2005-11-16  3:28       ` Ron McCall
2005-11-15  6:50     ` Vladimir Prus
2005-11-15 20:46       ` Ron McCall
2005-11-15 23:10         ` Jim Blandy [this message]
2005-11-15 23:25           ` Daniel Jacobowitz
2005-11-16  0:12             ` Jim Blandy
2005-11-16  0:38               ` Daniel Jacobowitz
2005-11-16  1:33                 ` Jim Blandy
2005-11-16  2:53                   ` Daniel Jacobowitz
     [not found]                   ` <20051116025218.GA27921@nevyn.them.org>
2005-11-16  2:54                     ` Jim Blandy
2005-11-16  2:56                       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f2776cb0511151510p1d7fe81dl7aa7a6b439b4622@mail.gmail.com \
    --to=jimb@red-bean.com \
    --cc=gdb@sources.redhat.com \
    --cc=ronald.mccall@snet.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).