This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb 7.0.1 opening many files when breakpoints are pending
Martin.Runge@rohde-schwarz.com wrote:
> Hi all,
>
> 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.
Scary...
>
> Scenario;
>
> break main
> <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
> is reached
>
> 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.
>
Guess you should collect some more concrete stats, e.g.: How many of
those open requests are successful and not just searches? How many are
re-opening an already opened file? How many are opening a just closed
one? Or track down what happens to a concrete file that shouldn't be
opened that often.
BTW, what is the performance with this load on a standard local file system?
>
> 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,
Maybe there is actually room for optimization. But I tend to believe you
are trying to address the wrong end first. If you seriously want to
bring down your development turn-around times, get Clearcase out of the
critical path. Really. Use a native build and test environment, set up a
modern DVCS, synchronizing with the repos only when required. But this
is getting off-topic for this list.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux