This is the mail archive of the
mailing list for the GDB project.
gdb 7.0.1 opening many files when breakpoints are pending
- From: Martin dot Runge at rohde-schwarz dot com
- To: gdb at sourceware dot org
- Date: Fri, 19 Feb 2010 17:07:57 +0100
- Subject: gdb 7.0.1 opening many files when breakpoints are pending
I observed gdb calling "open" many times on the same files when
breakpoints are still pending. About 80% of the open syscalls I traced via
strace go to std C headers, STL Headers and Qt Headers somewhere included
in the sources.
On a normal System, this is no Problem, because the filesystem cache still
knows these files and delivers them immediately. On slow network file
systems, this becomes a problem. SMB seems to have problems with client
side caching contacting the server for every open, even if the same file
was read less then a second before, even worse when ClearCase MVFS aka
Dynamic Views via SMB is involved.
<lot of code>
break A <- can be resolved at start
<little bit of code>
break B <- in a dynamically loaded .so, still pending when A
gdb calls "open" 10,000 times until it reaches breakpoint A when B is not
set, but 600,000 times when B is set. The Project has only 6000 source
files and the C++ and Qt Headers are far less then 600,000. In time this
is one minute versus 20 minutes! until breakpoint A is reached.
Now my question:
Why does gdb open all these files and where does it do it? The breakpoint
is specified as <sourcefile>:<line>, but the debug info in the binary
should be sufficient to resolve the address? I'll try to develop a path
if I understand why and where some of these "open" syscall can be avoided.
looking forward to possibly speeding up debugging here,