From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30253 invoked by alias); 12 Apr 2002 14:34:31 -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 30219 invoked from network); 12 Apr 2002 14:34:27 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 Apr 2002 14:34:27 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16w28J-0006Xe-00; Fri, 12 Apr 2002 10:34:35 -0400 Date: Fri, 12 Apr 2002 07:34:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: .n suffixes for function names in stabs debug info (GCC 3.1-based compiler) Message-ID: <20020412103435.A24938@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20020411181942.H29472@act-europe.fr> <20020411150444.A14251@nevyn.them.org> <20020412104307.C16134@act-europe.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020412104307.C16134@act-europe.fr> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00455.txt.bz2 On Fri, Apr 12, 2002 at 10:43:07AM +0200, Joel Brobecker wrote: > [I removed gcc@gcc.gnu.org, as this discussing is now taking a > GDB-specific turn] > > Summary: I define a function called "inside" nested into function main. > Compiling with a gcc-3 backend using -gstabs+, I found that GDB is > having problems putting a breakpoint on function "inside": > > > > (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. > > > >> > > I pointed the source of the problem to the stabs line, were the ".0" > suffix was now present. Daniel Jacobowitz kindly answered that > GCC is right to put this suffix in the name before the ':' : > > > According to that, your example: > > > .stabs "inside.0:f(1,1)=(1,1),inside.0,main",36,0,4,inside.0 > > > > should be: > > > .stabs "inside.0:f(1,1)=(1,1),inside,main",36,0,4,inside.0 > > What do you think of the scenario above? Is it acceptable that the user > has to use "inside.0" (and guess the right prefix) rather than "inside" > to break on this function? I suppose that this case does not happen very > often in C, and completion should help the user find which prefixes are > used. Certainly it isn't acceptable. > Since this happens more often in Ada, I'd like to fix it at least in the > ada mode. > > I have found two possibilities: > (1) either enhance our ada "mode" in GDB to support these suffixes > (I think this should not be too difficult, but other languages > would not benefit from it) > (2) or modify GDB in a language-independent manner. I'm not sure what > the best way to achieve this would be yet, maybe by stripping > these suffixes from the names read from the stabs info and from > the symbols table? But at the same time this may disturb the > support of other languages such as, maybe, c++. > > What do you think? The proper solution is: - urge the namespace/scope discussions onward. - Support reading those functions into the proper scope. At that point you'll have to reference them as 'main::inside', probably (or 'inside' if you're in main currently). Not an obvious syntax... but the most reasonable, I think. And the results of 'info func inside' will show a 'main::inside', which should be enough of a hint. Jim, that raises one question. How are we going to support searching for a name in all scopes, a la `info func'? It seems that it might be prohibitively more expensive than it is currently... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer