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


> 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


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