Re: inner block not inside outer block

[Paul Koning <pkoning@equallogic.com>]

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