This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 0/9] Absolute filenames
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 18 Jan 2013 16:30:15 +0400
- Subject: Re: [patch 0/9] Absolute filenames
- References: <20130117215803.GA16249@host2.jankratochvil.net>
> I do not understand why is there xfullpath at all. Why does exist "fullname"
> and GDB does not use just "realname" everywhere? There is:
> /* If a file was opened, canonicalize its filename. Use xfullpath
> rather than gdb_realpath to avoid resolving the basename part
> of filenames when the associated file is a symbolic link. This
> fixes a potential inconsistency between the filenames known to
> GDB and the filenames it prints in the annotations. */
> But such difference no longer works by default anyway, one would have to set
> 'set basenames-may-differ on'. And does Emacs still require it? This
> patchset tried to keep backward compatibility with the current state.
I think it was me who introduced this patch. I found:
http://www.sourceware.org/ml/gdb-patches/2002-03/msg00345.html
It was 10 years ago, and I am not quite certain of how relevant
that is. I know that we now deal with the naming scheme in a more
flexible way, so the symbolic links to create filenames with
the usual names are no longer necessary. This makes the situation
leading to the problem a little OBE. The problem itself, however,
might still be relevant.
It seems to me that the purpose of "set basenames-may-differ" is
slightly different from what the original report tried to achieve.
I will consult with the GPS team as well (GVD is now part of GPS).
> I have also noticed GDB does excessive use of stat syscalls for realpath.
> It tries to cache the info but each place caches it on its own and some places
> do not cache it. Moreover both xfullpath and gdb_realpath are called which
> duplicate the number of syscalls. And also most of the parent directories are
> stat-ed for each file again. This may be the reason for:
> Provide efficient source lookup for use by IDE
> http://sourceware.org/bugzilla/show_bug.cgi?id=12332
> I started coding some global cache for stat calls to unify all the caching
> across GDB but it was not finished / included in this patchset.
Yeah - I think this would be a very good improvement. 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?
--
Joel