Separate debuginfo file misidentifed with "remote:" acess

[Ulrich Weigand]

When doing cross-testing using a GDB built with --with-sysroot=remote: against a Ubuntu 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.

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)

[Ulrich Weigand (uweigand)]

Here's a mailing list discussion on some of the underlying issues:
http://sourceware.org/ml/gdb-patches/2009-11/msg00048.html

[Ulrich Weigand (uweigand)]

Fixed upstream and in Linaro GDB.