From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5599 invoked by alias); 19 Oct 2004 22:14:28 -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 5583 invoked from network); 19 Oct 2004 22:14:26 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 19 Oct 2004 22:14:26 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i9JMEK0T008899; Wed, 20 Oct 2004 00:14:20 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i9JMEKXL014616; Wed, 20 Oct 2004 00:14:20 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i9JMEKVj014613; Wed, 20 Oct 2004 00:14:20 +0200 (CEST) Date: Tue, 19 Oct 2004 22:14:00 -0000 Message-Id: <200410192214.i9JMEKVj014613@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: ezannoni@redhat.com CC: jimb@redhat.com, gdb-patches@sources.redhat.com In-reply-to: (message from Jim Blandy on 17 Oct 2004 14:57:22 -0500) Subject: [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> X-SW-Source: 2004-10/txt/msg00326.txt.bz2 From: Jim Blandy Date: 17 Oct 2004 14:57:22 -0500 Elena Zannoni writes: > > Jim, send a list of pointers (with URLs) to the patches and I'll take > care of them. Okay, great. Here are the ones that I know about: - 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: 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:32:34 -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