Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Paul Koning <pkoning@equallogic.com>
To: eliz@elta.co.il
Cc: gdb@sources.redhat.com
Subject: Re: inner block not inside outer block
Date: Mon, 29 Dec 2003 14:54:00 -0000	[thread overview]
Message-ID: <16368.16447.181349.29150@gargle.gargle.HOWL> (raw)
In-Reply-To: <ud6a9i3pa.fsf@elta.co.il>

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

 Eli> I've just compiled GDB 6.0 with DJGPP (patches to fix what was
 Eli> broken to follow shortly) using GCC 3.3.2, and while trying the
 Eli> classic "break main; run" test in GDB debugging itself, I see
 Eli> several messages like this:

 Eli> During symbol reading, inner block not inside outer block in
 Eli> internal_vproblem During symbol reading, inner block
 Eli> (0x1-0xffe289b8) not inside outer block (0x11b09a-0x11b2e0)
 Eli> During symbol reading, block at 0x1 out of order

 Eli> I've read the description of these messages in the manual, which
 Eli> seems to say that, as a user, I shouldn't worry about them.
 Eli> What I'm not sure about is what should I do as a
 Eli> _GDB_maintainer_.  Is this a GDB bug? a GCC bug? something
 Eli> specific to the DJGPP port of either or both of them? something
 Eli> else?  Should I report that somewhere or is it a known problem?

 Eli> (In case it matters, this GDB was compiled with DWARF-2 debug
 Eli> info.)

I recently had a battle with GDB 5.3 on the same issue -- which was
hidden because that message was turned off by default.

It turned out that the recovery code (in 5.3 anyway) for this
condition makes matters worse by fiddling with the start/end values of
the offending blocks.  This is a bad idea because the blocks in
question are in fact completely unrelated (it's anyone's guess why the
compiler is putting out such nonsense).  In one case, I was ending up
with a block whose start address was larger than its end address.  A
consequence of this was backtrace problems, caused by gdb
misidentifying which function a particular PC value belongs to.

I fixed this by inserting "continue;" immediately after the complain
message, i.e., not changing the start or end of either block and not
setting the superblock pointer when the other block clearly can't be
the superblock.

By the way, that was GDB for mips, which I think is ecoff, fed by gcc
3.0.1 or thereabouts.

    paul


  parent reply	other threads:[~2003-12-29 14:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-28 11:24 Eli Zaretskii
2003-12-28 18:46 ` Daniel Jacobowitz
2003-12-30 14:42   ` Eli Zaretskii
2003-12-30 15:27     ` Daniel Jacobowitz
2003-12-31  3:36       ` Daniel Berlin
2003-12-29 14:54 ` Paul Koning [this message]
2003-12-29 15:38   ` Eli Zaretskii
2003-12-29 16:06     ` Daniel Jacobowitz
2003-12-29 21:54       ` Eli Zaretskii
2003-12-29 16:17     ` Paul Koning
2003-12-30 18:01 David Anderson
2003-12-30 23:04 ` Eli Zaretskii

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=16368.16447.181349.29150@gargle.gargle.HOWL \
    --to=pkoning@equallogic.com \
    --cc=eliz@elta.co.il \
    --cc=gdb@sources.redhat.com \
    /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