[REASON FOUND] Re: gdb 7.0.1 opening many files when breakpoints are pending

[Martin dot Runge at rohde-schwarz dot com]

Hello all, Tom, Jan

Setting breakppoints with complete absolute path makes the difference.

I was able to track down this effect to a very simple example (filename 
"main.cpp"):


#include <iostream>
#include <string>

using namespace std;

int main( int argc, char *argv[] )
{
  string mystr("Hallo");

  cerr << mystr << endl;     // breakpoint here in line 10
  return 0;
}


Assuming this hello Wold example was compiled to an executable started in 
gdb while stracing "open" syscalls, the following effect can be observed 
when setting reakpoints:

break main          ->  works like expected ( opens no source file when 
setting BP, but main.cpp when hitting it)
break main.cpp:10   ->  works like expected 

break /full/path/to/main.cpp:10  -> 

open("/usr/include/c++/4.2/bits/locale_facets.tcc", O_RDONLY) = 8
open("/usr/include/c++/4.2/bits/locale_facets.tcc", O_RDONLY) = 8
open("/usr/include/c++/4.2/bits/stl_algobase.h", O_RDONLY) = 8
open("/usr/include/c++/4.2/bits/stl_algobase.h", O_RDONLY) = 8
open("/usr/include/c++/4.2/iostream", O_RDONLY) = 8
open("/usr/include/c++/4.2/iostream", O_RDONLY) = 8
open("/full/path/to/Debug/../main.cpp", O_RDONLY) = 8
open("/full/path/to/Debug/../main.cpp", O_RDONLY) = 8

hitting the breakpoint again opens just the source file

These are already eight calls to "open" for setting a single breakppoint 
in a three line program. When dynamically loaded .so are involved, this 
happens every time gdb stops in the dynamic linker trying to set the 
pending breakpoints. This is where the ridiculous number of 600.000 opens 
comes from.

Even this simple example shows that the same header files are openend 
multiple times. A "close" is happening in between, two. Can be traced, but 
ommitted here.

Why are these header files opened? Is there a good reason for it or can 
this possibly be optimized?

btw. I asked my boss to switch to project to a modern DVCS which I would 
prefer, too, but unfortunately he rejected.  :-)

best regards 
Martin