From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31477 invoked by alias); 12 Aug 2002 22:55:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31467 invoked from network); 12 Aug 2002 22:55:05 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 12 Aug 2002 22:55:05 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17eO5b-0007lf-00; Mon, 12 Aug 2002 17:55:07 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17eO5t-0000xv-00; Mon, 12 Aug 2002 18:55:25 -0400 Date: Mon, 12 Aug 2002 15:55:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: Line number problems with stabs and GCC 2.95.4 on FreeBSD/i386 Message-ID: <20020812225525.GA3516@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sources.redhat.com References: <200208122238.g7CMcdc5025808@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208122238.g7CMcdc5025808@elgar.kettenis.dyndns.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00116.txt.bz2 On Tue, Aug 13, 2002 at 12:38:39AM +0200, Mark Kettenis wrote: > I'm seeing quite a few regressions on FreeBSD/i386 with its default > compiler (which is based on GCC 2.95.4); the number of unexpected > failures went up from 94 to 142. Unfortunately I did not update my > source tree for a while, so I had some trouble tracking down the cause > of these regeressions. However, I'm pretty sure they're caused by an > interaction between Daniel's 2002-07-11 patch and incorrect debugging > info. It looks as if my version of GCC emits two N_FUN stabs for the > beginning of a function. This causes GDB to create two block > definitions: one that covers the entire function and one that has an > ending address equal to its starting address. The last one is bogus, > and causes breakpoints to be set before the end of a function > prologue. I suspect that Daniel's patch changes the ordering of the > block definitions, such that the bogus definition is used where the > correct one was used before. That's possible... I didn't really consider this case. That's the third creative way I've seen GCC break debug info recently... Does GCC even end the second N_FUN? > > Here is part of the output from objdump --stabs for the funcargs test > program from the testsuite: > > 48 FUN 0 78 0804846c 1404 call0a:F(0,1) > 49 PSYM 0 78 00000008 1418 c:p(0,1) > 50 PSYM 0 78 0000000c 1427 s:p(0,1) > 51 PSYM 0 78 00000010 1436 i:p(0,1) > 52 PSYM 0 78 00000014 1445 l:p(0,3) > 53 SLINE 0 80 00000006 0 > 54 SLINE 0 81 00000013 0 > 55 SLINE 0 82 00000017 0 > 56 SLINE 0 83 0000001d 0 > 57 SLINE 0 84 00000024 0 > 58 SLINE 0 85 0000002b 0 > 59 FUN 0 78 0804846c 1404 call0a:F(0,1) > 60 PSYM 0 78 00000008 1418 c:p(0,1) > 61 PSYM 0 78 0000000c 1427 s:p(0,1) > 62 PSYM 0 78 00000010 1436 i:p(0,1) > 63 PSYM 0 78 00000014 1445 l:p(0,3) > 64 LSYM 0 78 ffffffff 1454 c:(0,2) > 65 LSYM 0 78 fffffffc 1462 s:(0,8) > 66 FUN 0 0 0000002d 0 > > Is there an easy way to fix this, or should we just consider this > compiler to be broken? Some compilers emit the ending N_FUN and others don't. If we knew that the current compiler would, we could ignore the second N_FUN with the same name... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer