From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12039 invoked by alias); 10 Aug 2010 08:25:56 -0000 Received: (qmail 12017 invoked by uid 22791); 10 Aug 2010 08:25:52 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_DP,TW_YB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail02.rohde-schwarz.com (HELO mail02.rohde-schwarz.com) (80.246.32.97) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Aug 2010 08:25:49 +0000 In-Reply-To: To: markus.grunwald@gmx.de Cc: gdb@sourceware.org Subject: Antwort: Big speed differences when setting breakpoints MIME-Version: 1.0 X-KeepSent: 20E29A82:06FDDD18-C125777B:002E47F5; type=4; name=$KeepSent Message-ID: From: Martin.Runge@rohde-schwarz.com Date: Tue, 10 Aug 2010 08:25:00 -0000 Content-Type: text/plain; charset="US-ASCII" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00053.txt.bz2 Hi Markus, I was fighting with this issue, too. Especially, if the sources are located on a slow network share ( e.g. smb) it is extremely slow. When setting a breakpoint by sourcefile:lineNr, gdb searches the sybmol tables of all object files linked into the binary for the given Source file. If found, the symbol table holds the address for that breakpoint. For some reason unknown to me, gdb tries for every source and header file mentioned in the symbol table, if the source file is still there, or if it can be found via source path substitution, or if its a symlink by following it. So gdb opens and stats every file mentioned in the symbol table ( even stdio.h, .... ). (this is needed whenever the path to the sources differes between compiling and debugging) When giving just the filename, gdb takes the first matching filename from the symbol table, no need to open / stat files on disk. Please also see Thread titled "[PATCH] Avoid most open and stat syscalls when setting a breakpoint" in gdb patches mailinglist: http://www.cygwin.com/ml/gdb-patches/2010-04/msg00466.html Regards Martin "Markus Grunwald" Gesendet von: gdb-owner@sourceware.org 09.08.2010 08:29 An gdb@sourceware.org Kopie Thema Big speed differences when setting breakpoints Hello, Can somebody explain these differences? > (gdb) maint time 1 > (gdb) break /home/gru/projects/vxp/branches/branch-0-2-30-X/Dafit_Code/dafit2/dafit2/CPTApplication.cpp:370 > Breakpoint 1 at 0x8161436: file /home/gru/projects/vxp/branches/branch-0-2-30-X/Dafit_Code/dafit2/dafit2/CPTApplication.cpp, line 370. > Command execution time: 5.840365 compare it to this: > (gdb) break CPTApplication.cpp:370 > Breakpoint 1 at 0x8161436: file /home/gru/projects/vxp/branches/branch-0-2-30-X/Dafit_Code/dafit2/dafit2/CPTApplication.cpp, line 370. > Command execution time: 0.708044 Setting a breakpoint with the complete path is awfully slow, while it is ok when you give only the filename. /home is on an nfs mount where disk access is expensive, but even without nfs, the difference is quite big. I wrote a little benchmark and straced the "open" calls: % strace -eopen -o /tmp/gdb2.strace gdb dafit_x86.bin -x ~/gdb-benchmark-only-names.gdb % strace -eopen -o /tmp/gdb.strace gdb dafit_x86.bin -x ~/gdb-benchmark.gdb % wc -l /tmp/gdb.strace /tmp/gdb2.strace 88350 /tmp/gdb.strace 20 /tmp/gdb2.strace What? 80000 calls to "open" if I pass the whole path and only 20 otherwise? BTW: This is debian stables gdb: % dpkg -l gdb ||/ Name Version Description +++-===================================-===================================-====================================================================================== ii gdb 6.8-3 The GNU Debugger I would be happy if somebody could explain this behaviour.... Thanks, Markus Grunwald -- Markus Grunwald http://the-grue.de Registered Linux User Nr 101577 http://counter.li.org