From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13119 invoked by alias); 29 Dec 2003 16:06:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13112 invoked from network); 29 Dec 2003 16:05:59 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 29 Dec 2003 16:05:59 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Aazu1-0003hQ-VE; Mon, 29 Dec 2003 11:05:57 -0500 Date: Mon, 29 Dec 2003 16:06:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Paul Koning , gdb@sources.redhat.com Subject: Re: inner block not inside outer block Message-ID: <20031229160557.GA14166@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Paul Koning , gdb@sources.redhat.com References: <16368.16447.181349.29150@gargle.gargle.HOWL> <7491-Mon29Dec2003173616+0200-eliz@elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7491-Mon29Dec2003173616+0200-eliz@elta.co.il> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00275.txt.bz2 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 > > > > 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