From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12360 invoked by alias); 16 Nov 2001 22:02:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12321 invoked from network); 16 Nov 2001 22:02:19 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sourceware.cygnus.com with SMTP; 16 Nov 2001 22:02:19 -0000 Received: from cygnus.com (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA09598; Fri, 16 Nov 2001 14:02:16 -0800 (PST) Message-ID: <3BF58D22.6CA0AFF9@cygnus.com> Date: Wed, 07 Nov 2001 07:59:00 -0000 From: Michael Snyder Organization: Red Hat X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com, jimb@redhat.com Subject: Re: symtab.c change breaks assembly lang debugging References: <200111162015.fAGKF7g05478@reddwarf.cygnus.com> <20011116152941.A15960@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00101.txt.bz2 Daniel Jacobowitz wrote: > > On Fri, Nov 16, 2001 at 12:15:07PM -0800, Michael Snyder wrote: > > > > Jim, > > > > I presume the change below was meant as an optimization, but it's > > based on a false assumption -- that you can't have line numbers > > if you don't have block symbols. That premise is untrue if you > > are debugging assembly language source, where the assembler emits > > line syms but not block syms. This change breaks the test case > > for assembly source debugging, gdb.asm/asm-source.exp. > > > > You would not have noticed, because that test only works on a few > > targets right now (d10v being one of them). > > > > Patch from Peter Schauer: > > > > * symtab.c (find_pc_sect_line): If we can't find the function > > containing PC, we certainly won't have line number information for > > that location, so return zero immediately. > > > > OK, I should have thought of that. The problem is that this almost > always indicates a lack of debugging information, and GDB historically > copes very badly with not having any debugging information available. > Aside from Jim's address range cleanups, which are certainly a good > solution for the cases they can handle, I don't know what to do about > this. What need are you trying to address? Is it, as I surmised, an optimization? And if so, can we take it out until we think of a better way to do it? Michael