Antwort: Re: [PATCH] Avoid most open and stat syscalls when setting a breakpoint

[Martin.Runge@rohde-schwarz.com]

> > So, I think this patch is not correct, or at least, it changes gdb
> > incompatibly.  I don't know how much this symlink thing matters in
> > practice.  Maybe there is some other way to solve this problem, but I
> > haven't looked into it deeply.
>
> I agree on the conclusion - the change can be disruptive if the user
> uses symlinks.
> 
> However, I am wondering if this is worth considering, given how slow
> the IO on some filesystems can be (some users even use a remote FS,
> which is even worse). But the compatibility is a real issue.
> 

I agree that my patch breaks compatibility in case of symlinks. But I 
wonder if 
gdb can work correctly in all of these situations, anyway:

As gdb tries all source path entries, cwd and cdir applied to the given 
file and takes the 
first one that points to an existing file, this may easily fail in 
projects 
with duplicate filenames that only differ in their path. 

Second issue I see is the difference in how breakpoints are resolved when 
the source file is given with full path and just the filename. I 
am not sure if I understood the code completely, but I think the symlink 
case 
does not work when setting breakpoints without absolute path, either.

> It's not trivial to do the archeology and try to figure out how long
> we've had this change in AdaCore's tree, but I think it's been many
> years, and I believe from customer feedback that this has made a
> noticeable impact (we have some customers who are very sensitive to
> filesystem access explosions).
>
> I'm not sure how common (or uncommon) it is to use symlinks in source
> trees, and I'm not willing to take a bet on this. Peharps the only way
> forward is to has a user setting that allows us to turn the optimization
> off in the case when there are symlinks?
> 
> (just thinking out loud)

In frondends to gdb there is usually a small checkbox "set breakpoint with 
full sourcepath". 
When the user checks it he changes the behviour of the debugger to a much 
larger extend than 
he would expect.


Martin