From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1669 invoked by alias); 29 Dec 2003 15:38:41 -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 1661 invoked from network); 29 Dec 2003 15:38:40 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sources.redhat.com with SMTP; 29 Dec 2003 15:38:40 -0000 Received: from zaretski (pns03-195-8.inter.net.il [80.230.195.8]) by legolas.inter.net.il (Mirapoint Messaging Server MOS 3.3.8-GR) with ESMTP id BAG67634; Mon, 29 Dec 2003 17:38:33 +0200 (IST) Date: Mon, 29 Dec 2003 15:38:00 -0000 From: "Eli Zaretskii" To: Paul Koning Message-Id: <7491-Mon29Dec2003173616+0200-eliz@elta.co.il> CC: gdb@sources.redhat.com In-reply-to: <16368.16447.181349.29150@gargle.gargle.HOWL> (message from Paul Koning on Mon, 29 Dec 2003 09:54:55 -0500) Subject: Re: inner block not inside outer block Reply-to: Eli Zaretskii References: <16368.16447.181349.29150@gargle.gargle.HOWL> X-SW-Source: 2003-12/txt/msg00274.txt.bz2 > 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. > 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. Anyway, thanks for the feedback.