This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]