* Big speed differences when setting breakpoints
@ 2010-08-09 6:30 Markus Grunwald
2010-08-09 16:37 ` Tom Tromey
2010-08-10 8:25 ` Antwort: " Martin.Runge
0 siblings, 2 replies; 3+ messages in thread
From: Markus Grunwald @ 2010-08-09 6:30 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Big speed differences when setting breakpoints
2010-08-09 6:30 Big speed differences when setting breakpoints Markus Grunwald
@ 2010-08-09 16:37 ` Tom Tromey
2010-08-10 8:25 ` Antwort: " Martin.Runge
1 sibling, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2010-08-09 16:37 UTC (permalink / raw)
To: Markus Grunwald; +Cc: gdb
>>>>> "Markus" == Markus Grunwald <markus.grunwald@gmx.de> writes:
Markus> Can somebody explain these differences?
I am going to guess it is this:
http://sourceware.org/bugzilla/show_bug.cgi?id=8367
There have been several patches for this. I'm not sure what has
happened with them. For my part I am not sure how important the
symlink-with-different-base-name case is.
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
* Antwort: Big speed differences when setting breakpoints
2010-08-09 6:30 Big speed differences when setting breakpoints Markus Grunwald
2010-08-09 16:37 ` Tom Tromey
@ 2010-08-10 8:25 ` Martin.Runge
1 sibling, 0 replies; 3+ messages in thread
From: Martin.Runge @ 2010-08-10 8:25 UTC (permalink / raw)
To: markus.grunwald; +Cc: gdb
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-08-10 8:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-09 6:30 Big speed differences when setting breakpoints Markus Grunwald
2010-08-09 16:37 ` Tom Tromey
2010-08-10 8:25 ` Antwort: " Martin.Runge
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).