Antwort: Big speed differences when setting breakpoints

[Martin dot Runge at rohde-schwarz dot com]

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" <markus.grunwald@gmx.de> 
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