From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28202 invoked by alias); 13 Aug 2002 06:31:47 -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 28195 invoked from network); 13 Aug 2002 06:31:45 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250) by sources.redhat.com with SMTP; 13 Aug 2002 06:31:45 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g7D6VeAH000239; Tue, 13 Aug 2002 08:31:40 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.5/8.12.5) with ESMTP id g7D6Ve74000311; Tue, 13 Aug 2002 08:31:40 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.5/8.12.5/Submit) id g7D6Va0Z000306; Tue, 13 Aug 2002 08:31:36 +0200 (CEST) Date: Mon, 12 Aug 2002 23:31:00 -0000 Message-Id: <200208130631.g7D6Va0Z000306@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@mvista.com CC: gdb@sources.redhat.com In-reply-to: <20020812225525.GA3516@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 12 Aug 2002 18:55:25 -0400) Subject: Re: Line number problems with stabs and GCC 2.95.4 on FreeBSD/i386 References: <200208122238.g7CMcdc5025808@elgar.kettenis.dyndns.org> <20020812225525.GA3516@nevyn.them.org> X-SW-Source: 2002-08/txt/msg00117.txt.bz2 Date: Mon, 12 Aug 2002 18:55:25 -0400 From: Daniel Jacobowitz 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? Nope. We have two N_FUN's with call0a as its name and only a single N_FUN with 0 as its name to end the function. After that last N_FUN a new function starts. 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... If you see an easy way to fix this, please go ahead, otherwise I'll try to come up with a patch myself. Thanks, Mark