From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1443 invoked by alias); 9 Nov 2004 19:54:55 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1363 invoked from network); 9 Nov 2004 19:54:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Nov 2004 19:54:48 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iA9Jslun026262 for ; Tue, 9 Nov 2004 14:54:47 -0500 Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA9Jsfr19473; Tue, 9 Nov 2004 14:54:41 -0500 To: Mark Kettenis Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't apply line-number tweaks for non-GCC compilers References: <16752 dot 3082 dot 255249 dot 837515 at localhost dot redhat dot com> <200410192215.i9JMF2NS014623@elgar.sibelius.xs4all.nl> <200411091315.iA9DFrdB090647@elgar.sibelius.xs4all.nl> From: Jim Blandy Date: Tue, 09 Nov 2004 19:54:00 -0000 In-Reply-To: <200411091315.iA9DFrdB090647@elgar.sibelius.xs4all.nl> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00174.txt.bz2 For what it's worth, this change implements the suggestion I made. Mark Kettenis writes: > Date: Wed, 20 Oct 2004 00:15:02 +0200 (CEST) > From: Mark Kettenis > > Ping! > > - GDB's stabs reader tweaks line number information, in a way that's > not appropriate for non-GCC stabs. Mark Kettenis posted a patch, > and I suggested a revision; I think that's where it stands. > > http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html > > I had a follow-up patch, but I lost it when I accidentally did an rm > -rf of my GDB working directory. Anyway, here's a new one that > implements Jim's suggestion. OK? > > I'd really like to check this in on the new release branch too, since > I promised to fix this a long time ago. > > Mark > > > Index: ChangeLog > from Mark Kettenis > > * dbxread.c (process_one_symbol): Do not adjust address of first > N_SLINE stab for a function for code generated by non-GCC > compilers. > > > Index: dbxread.c > =================================================================== > RCS file: /cvs/src/src/gdb/dbxread.c,v > retrieving revision 1.74 > diff -u -p -r1.74 dbxread.c > --- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74 > +++ dbxread.c 19 Oct 2004 20:45:53 -0000 > @@ -2927,11 +2927,26 @@ process_one_symbol (int type, int desc, > /* Relocate for dynamic loading and for ELF acc fn-relative syms. */ > valu += function_start_offset; > > - /* If this is the first SLINE note in the function, record it at > - the start of the function instead of at the listed location. */ > + /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the > + middle of the prologue instead of right at the start of the > + function. To deal with this we record the address for the > + first N_SLINE stab to be the start of the function instead of > + the listed location. We really shouldn't to this. When > + compiling with optimization, this first N_SLINE stab might be > + optimized away. Other (non-GCC) compilers don't emit this > + stab at all. There is no real harm in having an extra > + numbered line, although it can be a bit annoying for the > + user. However, it totally screws up our testsuite. > + > + So for now, keep adjusting the address of the first N_SLINE > + stab, but only for code compiled with GCC. */ > + > if (within_function && sline_found_in_function == 0) > { > - record_line (current_subfile, desc, last_function_start); > + if (processing_gcc_compilation == 2) > + record_line (current_subfile, desc, last_function_start); > + else > + record_line (current_subfile, desc, valu); > sline_found_in_function = 1; > } > else