Re: inner block not inside outer block

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Dec 29, 2003 at 05:36:17PM +0200, Eli Zaretskii wrote:
> > 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).
> 
> Could you please elaborate on the ``blocks in question are in fact
> completely unrelated'' issue?  Are you saying that the ``inner'' block
> is unrelated to the ``outer'' block?
> 
> Also, do I understand correctly that you consider this a compiler bug?
> I tend to think that as well, so I googled for similar messages, in
> the hope that I will hit a discussion on some GCC forum that would
> shed some light on this, but came up with nothing useful.
> 
> > 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.
> 
> Perhaps we should commit such a change; it's not in the CVS AFAICS.

Hmm.... maybe.  I've learned that the business of trying to guess what
inconsistent debug information means is a pretty bad one.  There's
probably another broken version of GCC where the existing fixup is
better.

> > By the way, that was GDB for mips, which I think is ecoff, fed by gcc
> > 3.0.1 or thereabouts.
> 
> What was the format of the debug info?  Was it DWARF2, by any chance,
> and if so, did you try stabs?  In my case, the object format is COFF
> and the debug info is DWARF2.

No, it would probably have been stabs-in-mdebug.  GCC 3.0.1 didn't
support DWARF2 for MIPS targets.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer