Re: inner block not inside outer block

Daniel Jacobowitz
2003-12-29T16:06:00Z

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