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
next prev 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