[patch 0/9] Absolute filenames

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi,

http://sourceware.org/gdb/wiki/ArcherBranchManagement
archer-jankratochvil-absdir

patchset is the full variant of former (non-checked in):
	[patchv2] GDB 7.2: new feature for "backtrace" that cuts path to file (remain filename)
	http://sourceware.org/ml/gdb-patches/2012-11/msg00957.html
	http://sourceware.org/ml/gdb-patches/2012-12/msg00002.html
	Message-ID: <20121130185653.GA15394@host2.jankratochvil.net>

So that "set filename-display" applies in any case of GDB handling of
filenames in any command, both on output and also also on input.

One may consider making "set filename-display absolute" to be the default in
the future but such change is not in this patch.

Patchset also fixes some search/expansion bugs related to absolute and
relative filenames.

Currently GDB handles these kinds of files:
 * relative filename - for example "./gdb.base/return.c"
   Using variable name "filename".
 * absolute filename from xfullpath "/path/to/.../testsuite/gdb.base/return.c".
   Notice the trailing part "./gdb.base/return.c" does not match it via
   compare_filenames_for_search.
   It is returned from symtab_to_fullname.
   Using variable name "fullname".
 * absolute filename from gdb_realpath - they are like from xfullpath but
   xfullpath does not resolve the very last filename element; gdb_realpath does.
   Using variable name "realname".
 * raw absolute filename - used in macros - such
   as "/path/to/.../testsuite/./gdb.base/return.c" which does
   This variant was removed.

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 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.

The primary reason for this patch was that GDB was using only "filename"
everywhere.  Therefore "testsuite/gdb.base/return.c" could never work with
compare_filenames_for_search as it needs also COMP_DIR for the comparison.

Patchset includes:
 * Renames of variables so that their name matches their kind of content.
   For example "filename" is from DW_AT_name and not from xfullpath etc.
   I am aware some such naming violatios were still left over.
 * Various unrelated fixes I found during extending the code to be fully aware
   of absolute filenames.  I tried to cover them with testcases.
   Some of the fixes are reproducible only when using .gdb_index.

GDB is compilable incrementally but it may get broken with patches partially
applied.  I will check it in in the future in some merged form (to prevent git
bisect breakage).

No regressions on {x86_64,x86_64-m32,i686}-fedora18-linux-gnu and with
gdbindex (some fixed bugs get exposed only with gdbindex).


Thanks,
Jan