gdb 7.0.1 opening many files when breakpoints are pending

[Martin dot Runge at rohde-schwarz dot com]

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.

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.


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,

best regards
Martin