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

[Joel Brobecker <brobecker@adacore.com>]

> Martin> I think that most of these checks are not neccessary, e.g. to
> Martin> compare if
> Martin> /home/me/project/source/main.cpp
> Martin> becomes the same file as  <iostream>  when trying all source paths on 
> Martin> main.cpp. The patch below leaves the described search loop when the 
> Martin> basename from the symtab and the basename from the break command do not 
> Martin> match, as they wont match by appliing different paths either.
> 
> ISTR seeing this same patch in the past.

Me too - I just got a little surprise today while looking at AdaCore's
diff, finding the exact type of patch in AdaCore's tree as well :-o.

> 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.

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)

-- 
Joel