This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Antwort: Re: [PATCH] Avoid most open and stat syscalls when setting a breakpoint
- From: Martin dot Runge at rohde-schwarz dot com
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, Tom Tromey <tromey at redhat dot com>
- Date: Wed, 28 Apr 2010 10:53:27 +0200
- Subject: Antwort: Re: [PATCH] Avoid most open and stat syscalls when setting a breakpoint
> > 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