From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14364 invoked by alias); 11 Apr 2002 16:19:46 -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 14312 invoked from network); 11 Apr 2002 16:19:44 -0000 Received: from unknown (HELO dublin.ACT-Europe.FR) (212.157.227.154) by sources.redhat.com with SMTP; 11 Apr 2002 16:19:44 -0000 Received: from berlin.ACT-Europe.FR (berlin.int.act-europe.fr [10.10.0.169]) by dublin.ACT-Europe.FR (Postfix) with ESMTP id 5173B229E37; Thu, 11 Apr 2002 18:19:43 +0200 (MET DST) Received: by berlin.ACT-Europe.FR (Postfix, from userid 507) id BB13F980; Thu, 11 Apr 2002 18:19:42 +0200 (CEST) Date: Thu, 11 Apr 2002 09:19:00 -0000 From: Joel Brobecker To: gcc@gcc.gnu.org Cc: gdb-patches@sources.redhat.com Subject: .n suffixes for function names in stabs debug info (GCC 3.1-based compiler) Message-ID: <20020411181942.H29472@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-SW-Source: 2002-04/txt/msg00416.txt.bz2 The code that triggered this question was written in Ada but I reproduced it using a small C program. This C example may seem a bit unusual, but the root problem occurs quite often in usual situation when writting code in Ada, for instance when using overloading, or nested functions. Here is a small program: << int main (void) { void inside (void) {} return 0; } >> When compiled using the following command: % gcc -gstabs+ -S hello.c GCC generates the following stabs for inside(): << .stabs "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0 ^^ || >> This is happening on my x86-linux machine, but I suspect this to be target independent. This ".0" suffix, which was not generated with GCC-2 backends, is causing problems to GDB: << (gdb) b inside Function "inside" not defined. (gdb) b inside.0 <<---- Argh, need to give the name with the (right!) suffix Breakpoint 1 at 0x8048579: file hello.c, line 4. >> Do you think that GCC is right in putting these suffixes in the function name? I see several options: (1) GCC is not right, and the suffix should not be there, GDB will be fine again (2) GCC is right, and GDB should just strip these suffixes while reading the stabs information. Disambiguation should be done by other means (eg. a multiple choice question) (3) GCC is right, and GDB should is right too. The C user need to supply the full function name, including the suffix (not appealing at all for the Ada users) The Stabs reference manual is not very acurate on this issue. The example given in section "Nested procedures" seem to indicate that (1) is the right answer: .stabs "baz:f1,baz,bar",36,0,0,_baz.15 But is not quite clear on this particular issue. One side-effect of this approach is that the function name in the stabs information becomes different from the name stored in the symbols table. But should the name stored in the symbol table also contain this suffix? If it turns out that (1) is the correct answer, I'll be happy to work on a fix and discuss it on gcc-patches. -- Joel