This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 0/9] Absolute filenames
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 18 Jan 2013 20:21:44 +0100
- Subject: Re: [patch 0/9] Absolute filenames
On Fri, 18 Jan 2013 13:30:15 +0100, Joel Brobecker wrote:
> I think it was me who introduced this patch. I found:
> http://www.sourceware.org/ml/gdb-patches/2002-03/msg00345.html
[...]
> It seems to me that the purpose of "set basenames-may-differ" is
> slightly different from what the original report tried to achieve.
I have found basenames-may-differ does not help the case from the mail above
that still:
(gdb) break toto.C:4
No source file named toto.C
Fixing this would mean a performance regression and I find it outside of the
scope of this patchset.
> I am wondering what policy we could use to determine whether the cache
> should be invalidated or not. What if the user deletes a file that has been
> already stat-ed?
There is already forget_cached_source_info_for_objfile and
forget_cached_source_info, the global cache would just continue to honor this
policy. But that is offtopic for this patchset.
On Fri, 18 Jan 2013 14:55:02 +0100, Joel Brobecker wrote:
> Just got an answer, and they are confident that the initial problem
> should not affect them anymore - or said differently, even if
> the filename was a symbolic link and that symbolic link was resolved,
> the debugger front-end should not be confused by it.
OK, that is a great simplification + optimization, I will do that simple step
of replacing/removing xfullpath by gdb_realpath on top of this patchset.
Thanks,
Jan