inner block not inside outer block
Paul Koning
pkoning@equallogic.com
Mon Dec 29 16:17:00 GMT 2003
>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:
>> Date: Mon, 29 Dec 2003 09:54:55 -0500 From: Paul Koning
>> <pkoning@equallogic.com>
>>
>> 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).
Eli> Could you please elaborate on the ``blocks in question are in
Eli> fact completely unrelated'' issue? Are you saying that the
Eli> ``inner'' block is unrelated to the ``outer'' block?
What I meant is that the address ranges weren't anywhere near each
other, but they did look like valid ranges for blocks somewhere in the
program. So I concluded that the problem was that unrelated blocks
were being tied together by mistake.
Eli> Also, do I understand correctly that you consider this a
Eli> compiler bug? I tend to think that as well, so I googled for
Eli> similar messages, in the hope that I will hit a discussion on
Eli> some GCC forum that would shed some light on this, but came up
Eli> with nothing useful.
After thinking about it some more I realize that this is an
unsupported assumption. As one of the other messages just now points
out, it could be a gdb but (in reading the data), a compiler bug, or a
linker bug.
I have no data to narrow it down better than that, and my skills in
this area aren't really adequate to do so.
>> 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.
Eli> Perhaps we should commit such a change; it's not in the CVS
Eli> AFAICS.
>> By the way, that was GDB for mips, which I think is ecoff, fed by
>> gcc 3.0.1 or thereabouts.
Eli> What was the format of the debug info? Was it DWARF2, by any
Eli> chance, and if so, did you try stabs? In my case, the object
Eli> format is COFF and the debug info is DWARF2.
Sorry, I'm still learning this stuff... Stabs, I believe -- the
default MIPS format for GCC 3.0.1. I don't think Dwarf-2 is even
supported in that target/version.
paul
More information about the Gdb
mailing list