From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32347 invoked by alias); 7 Oct 2011 13:53:35 -0000 Received: (qmail 32334 invoked by uid 22791); 7 Oct 2011 13:53:34 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate2.uk.ibm.com (HELO mtagate2.uk.ibm.com) (194.196.100.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Oct 2011 13:53:14 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate2.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p97DrBhv006730 for ; Fri, 7 Oct 2011 13:53:12 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p97DrBGA2523378 for ; Fri, 7 Oct 2011 14:53:11 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p97DrB9n010547 for ; Fri, 7 Oct 2011 07:53:11 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p97Dr9LA010508; Fri, 7 Oct 2011 07:53:09 -0600 Message-Id: <201110071353.p97Dr9LA010508@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Fri, 07 Oct 2011 15:53:09 +0200 Subject: [rfc] False separate debuginfo warning with "remote:" access To: gdb-patches@sourceware.org Date: Fri, 07 Oct 2011 13:53:00 -0000 From: "Ulrich Weigand" Cc: jan.kratochvil@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00199.txt.bz2 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