From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22501 invoked by alias); 3 Dec 2005 14:22:13 -0000 Received: (qmail 22492 invoked by uid 22791); 3 Dec 2005 14:22:13 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 Dec 2005 14:22:10 +0000 Received: from white ([68.9.65.164]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051203142203.KAWI14098.eastrmmtao05.cox.net@white>; Sat, 3 Dec 2005 09:22:03 -0500 Received: from bob by white with local (Exim 3.36 #1 (Debian)) id 1EiYGr-0003e0-00; Sat, 03 Dec 2005 09:21:49 -0500 Date: Sat, 03 Dec 2005 14:22:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: Vladimir Prus , gdb@sources.redhat.com Subject: Re: Filename with "./" in breakpoint command Message-ID: <20051203142149.GC10592@white> Mail-Followup-To: Eli Zaretskii , Vladimir Prus , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00038.txt.bz2 On Sat, Dec 03, 2005 at 04:17:45PM +0200, Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Sat, 03 Dec 2005 15:55:10 +0300 > > > > $ ~/build/gdb-cvs/gdb/gdb tracepoints > > GNU gdb 6.4.50.20051121-cvs > > (gdb) b ./tracepoints.cpp:12 > > No source file named ./tracepoints.cpp. > > Breakpoint 1 (./tracepoints.cpp:12) pending. > > (gdb) b tracepoints.cpp:12 > > Breakpoint 2 at 0x80483c4: file tracepoints.cpp, line 12. > > (gdb) quit > > $ ls tracepoints.cpp > > tracepoints.cpp > > > > It looks like leading "./" in file name confuses gdb. This "./" thing is > > send by KDevelop in some cases. > > What are the actual source file names recorded in the debug info? > Please show us that, and we will be able to reason whether this is a > feature, a bug, or a missing feature. Eli, I can reproduce this like this, tmp/ one/ uut.c uut.h two/ uut.c uut.h main.c If I compile each file in there own directory with -g and then link in directory two/ and then start GDB from there, the command b uut.c:5 works for me and b ./uut.c:5 doesn't. If I compile gcc -S uut.c in either directory, the assembly file says the name is "uut.c". Is there a better way to tell you what the debug info says? Bob Rossi