From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21419 invoked by alias); 29 Dec 2003 14:54:58 -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 21412 invoked from network); 29 Dec 2003 14:54:57 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sources.redhat.com with SMTP; 29 Dec 2003 14:54:57 -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 hBTEsvf9017738 for ; Mon, 29 Dec 2003 09:54:57 -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 hBTEsuiu017733; Mon, 29 Dec 2003 09:54:57 -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 hBTEstA18748; Mon, 29 Dec 2003 09:54:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16368.16447.181349.29150@gargle.gargle.HOWL> Date: Mon, 29 Dec 2003 14:54:00 -0000 From: Paul Koning To: eliz@elta.co.il Cc: gdb@sources.redhat.com Subject: Re: inner block not inside outer block References: X-SW-Source: 2003-12/txt/msg00273.txt.bz2 >>>>> "Eli" == Eli Zaretskii writes: Eli> I've just compiled GDB 6.0 with DJGPP (patches to fix what was Eli> broken to follow shortly) using GCC 3.3.2, and while trying the Eli> classic "break main; run" test in GDB debugging itself, I see Eli> several messages like this: Eli> During symbol reading, inner block not inside outer block in Eli> internal_vproblem During symbol reading, inner block Eli> (0x1-0xffe289b8) not inside outer block (0x11b09a-0x11b2e0) Eli> During symbol reading, block at 0x1 out of order Eli> I've read the description of these messages in the manual, which Eli> seems to say that, as a user, I shouldn't worry about them. Eli> What I'm not sure about is what should I do as a Eli> _GDB_maintainer_. Is this a GDB bug? a GCC bug? something Eli> specific to the DJGPP port of either or both of them? something Eli> else? Should I report that somewhere or is it a known problem? Eli> (In case it matters, this GDB was compiled with DWARF-2 debug Eli> info.) I recently had a battle with GDB 5.3 on the same issue -- which was hidden because that message was turned off by default. 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). In one case, I was ending up with a block whose start address was larger than its end address. A consequence of this was backtrace problems, caused by gdb misidentifying which function a particular PC value belongs to. 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. By the way, that was GDB for mips, which I think is ecoff, fed by gcc 3.0.1 or thereabouts. paul