From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19567 invoked by alias); 12 Aug 2002 22:38: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 19417 invoked from network); 12 Aug 2002 22:38:45 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (62.163.169.250) by sources.redhat.com with SMTP; 12 Aug 2002 22:38: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 g7CMcir9001387 for ; Tue, 13 Aug 2002 00:38:44 +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 g7CMchNf025811 for ; Tue, 13 Aug 2002 00:38:43 +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 g7CMcdc5025808; Tue, 13 Aug 2002 00:38:39 +0200 (CEST) Date: Mon, 12 Aug 2002 15:38:00 -0000 Message-Id: <200208122238.g7CMcdc5025808@elgar.kettenis.dyndns.org> To: gdb@sources.redhat.com Subject: Line number problems with stabs and GCC 2.95.4 on FreeBSD/i386 From: Mark Kettenis X-SW-Source: 2002-08/txt/msg00113.txt.bz2 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. 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? Mark