From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17718 invoked by alias); 16 Nov 2001 22:19:22 -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 17680 invoked from network); 16 Nov 2001 22:19:21 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sourceware.cygnus.com with SMTP; 16 Nov 2001 22:19:21 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 164rKf-0008RY-00; Fri, 16 Nov 2001 17:19:33 -0500 Date: Wed, 07 Nov 2001 08:02:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com, jimb@redhat.com Subject: Re: symtab.c change breaks assembly lang debugging Message-ID: <20011116171933.A32310@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com, jimb@redhat.com References: <200111162015.fAGKF7g05478@reddwarf.cygnus.com> <20011116152941.A15960@nevyn.them.org> <3BF58D22.6CA0AFF9@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BF58D22.6CA0AFF9@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00102.txt.bz2 On Fri, Nov 16, 2001 at 02:03:14PM -0800, Michael Snyder wrote: > 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? No, it isn't an optimization. It was meant to be a sanity check. In the presence of stabs, and multiple code sections, the address ranges for a symtab become invalid. Suppose that you have libstdc++ with stabs, and a program with no debug info. Suppose you try to breakpoint at main. Libstdc++'s objects have a start address before main, because it is linked first, but the code is not in that location. It's up in the linkonce sections, after main, because *(.text) is first in the linker script. We call find_pc_sect_line, and it tells us that the "line" for main is in libstdc++. So the breakpoint gets set at the beginning of that "line" - in libstdc++! Not useful. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer