From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24673 invoked by alias); 17 Apr 2009 17:30:45 -0000 Received: (qmail 24665 invoked by uid 22791); 17 Apr 2009 17:30:44 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Apr 2009 17:30:34 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 6DC9410967; Fri, 17 Apr 2009 17:30:32 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 2DC5310965; Fri, 17 Apr 2009 17:30:32 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LurtX-0003UE-4f; Fri, 17 Apr 2009 13:30:31 -0400 Date: Fri, 17 Apr 2009 17:30:00 -0000 From: Daniel Jacobowitz To: Christophe LYON Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: [PATCH] obvious pattern fix in gdb.base/step-line.exp Message-ID: <20090417173031.GA13377@caradoc.them.org> Mail-Followup-To: Christophe LYON , Joel Brobecker , gdb-patches@sources.redhat.com References: <49CCDB3D.5010302@st.com> <20090327184726.GW9472@adacore.com> <49D083FB.6020108@st.com> <20090330170216.GB9472@adacore.com> <49D21E7E.8080708@st.com> <20090401183240.GD8766@adacore.com> <49D47C75.9000206@st.com> <49E8B701.1000402@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E8B701.1000402@st.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00451.txt.bz2 On Fri, Apr 17, 2009 at 07:06:09PM +0200, Christophe LYON wrote: > However, from GDB, using "maintenance print symbols", I noticed that > quite a few lines have become "0" instead of meaningful values. In turn, > I thinks this makes skip_prologue do something wrong. > > What I dont' understand currently is where those "0" line entries come > from? Is there any verbose flag or maintenance command I could use to > understand how the Dwarf debug_line info is parsed? Not really, but it's pretty straightforward to step through. GDB uses line 0 internally to represent a lack of line number information. This is required because the line table uses half-ranges; a line number and a start address. We get a line 0 at file switch events or at DW_LNS_end_of_sequence. There's some hairy bits to make sure the 0 appears 'before' any other line marker at the same address. -- Daniel Jacobowitz CodeSourcery