[rfc] False separate debuginfo warning with "remote:" access

["Ulrich Weigand" <uweigand@de.ibm.com>]

Hello,

when doing cross-testing using a GDB built with --with-sysroot=remote:
against an Ubuntu ARM distribution, test cases will fail due to spurious
warnings along the lines of:

  warning: the debug information found in
  "remote:/lib/arm-linux-gnueabi/libm-2.13.so" does not match
  "remote:/lib/arm-linux-gnueabi/libm.so.6" (CRC mismatch).

This is due to a combination of factors:

On the target system, /lib/arm-linux-gnueabi/libm.so.6 is a symlink to
libm-2.13.so. That file /lib/arm-linux-gnueabi/libm-2.13.so had its
debuginfo stripped and carries a .gnu_debuglink section pointing to
"libm-2.13.so". The separate debuginfo is in a file (that would be
installed to) /usr/lib/debug/lib/arm-linux-gnueabi/libm-2.13.so

On the host system, GDB will take the base filename from the .gnu_debuglink
section and search a variety of paths for the debuginfo file. These include
/lib/arm-linux-gnueabi itself, as well as /lib/arm-linux-gnueabi/.debug and
/usr/lib/debug/lib/arm-linux-gnueabi.

Due to the combination of the factors that the debuginfo file may have the
same basename as the underlying shared library file, and that the debuginfo
directory search path includes the directory containing the underlying
shared library file, it may happen that one of the files considered as
potential debuginfo file is actually the original shared library itself.

Since GDB will then check CRCs and determine that the shared library is
not actually itself the debuginfo file, we would get a warning as above.
To avoid this spurious warning, GDB will omit printing it if it detects
the situation that the attempted debuginfo is actually the underlying
library.

For this purpose, GDB will consider the two files identical if either of
those two checks succeed: the filenames are identical, or "stat" on both
files returns an identical device/inode pair.  Note that the "stat" check
was added by Jan to fix this very problem on (native) Debian:
http://sourceware.org/ml/gdb-patches/2009-11/msg00048.html

Usually, the filename check will suffice (and this works with "remote:"
access too). However, the filename check fails if the shared library is
referenced via a symbolic link as in this case. Normally, the "stat" check
would still catch this situation. However, with "remote:" access, "stat"
is not implemented.

To fix this, either of the following two approaches could be employed:
- Implement "stat" for the "remote:" file access protocol (but this would
  imply extending the remote protocol, and wouldn't help with old gdbservers
  on the other side)
- Omit the potentially spurious warning if the remote protocol is used to
  access the file (but this would also omit the warning if we get a real
  debuginfo mismatch due to out-of-date debuginfo)

Any thoughs?  Am I missing another option here?

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com