Re: inner block not inside outer block

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "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