From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16611 invoked by alias); 29 Dec 2003 16:17:28 -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 16603 invoked from network); 29 Dec 2003 16:17:27 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 29 Dec 2003 16:17:27 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hBTGHRf9019260 for ; Mon, 29 Dec 2003 11:17:27 -0500 Received: from deneb.dev.equallogic.com (deneb [172.16.1.99]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id hBTGHRiu019255; Mon, 29 Dec 2003 11:17:27 -0500 Received: from localhost.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.6) with ESMTP id hBTGHQx25548; Mon, 29 Dec 2003 11:17:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16368.21398.458932.829070@gargle.gargle.HOWL> Date: Mon, 29 Dec 2003 16:17:00 -0000 From: Paul Koning To: eliz@elta.co.il Cc: gdb@sources.redhat.com Subject: Re: inner block not inside outer block References: <16368.16447.181349.29150@gargle.gargle.HOWL> <7491-Mon29Dec2003173616+0200-eliz@elta.co.il> X-SW-Source: 2003-12/txt/msg00276.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: >> 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). 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