From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8974 invoked by alias); 2 Nov 2009 21:53:03 -0000 Received: (qmail 8966 invoked by uid 22791); 2 Nov 2009 21:53:03 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Nov 2009 21:52:58 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id B57AE10EA3; Mon, 2 Nov 2009 21:52:56 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 996AC10E94; Mon, 2 Nov 2009 21:52:56 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1N54pb-0005NN-4W; Mon, 02 Nov 2009 16:52:55 -0500 Date: Mon, 02 Nov 2009 21:53:00 -0000 From: Daniel Jacobowitz To: Jan Kratochvil , gdb-patches@sourceware.org Subject: Recent separate debug file warning caused Debian regressions Message-ID: <20091102215255.GA19425@caradoc.them.org> Mail-Followup-To: Jan Kratochvil , gdb-patches@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes 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: 2009-11/txt/msg00034.txt.bz2 One of your patches in the last few days caused at least these regressions for me: -PASS: gdb.base/annota1.exp: run until main breakpoint +FAIL: gdb.base/annota1.exp: run until main breakpoint Running /space/fsf/commit/src/gdb/testsuite/gdb.mi/mi-async.exp ... +FAIL: gdb.mi/mi-async.exp: start: send (failed to resume) PASS: gdb.mi/mi-async.exp: start: stop PASS: gdb.mi/mi-async.exp: CLI next: stop +FAIL: gdb.mi/mi-async.exp: restart: send (failed to resume) PASS: gdb.mi/mi-async.exp: restart: stop -PASS: gdb.mi/mi-nonstop-exit.exp: mi runto main -PASS: gdb.mi/mi-nonstop-exit.exp: finished exec continue -PASS: gdb.mi/mi-nonstop-exit.exp: breakpoint at main -PASS: gdb.mi/mi-nonstop-exit.exp: mi runto main -PASS: gdb.mi/mi-nonstop-exit.exp: finished exec continue (2) +ERROR: Unable to start target +ERROR: mi-nonstop-exit.exp tests suppressed It's definitely one of the last four patches you committed, and I suspect it's the warning patch. I believe the problem is this message: warning: the debug information found in "/lib/libm-2.9.so" does not match "/lib/libm.so.6" (CRC mismatch). It's upsetting the testsuite. I don't know why we're calculating a CRC for /lib/libm-2.9.so, which is of course the same library - not a separate debug file - so no wonder the CRC doesn't match, it's the CRC of the debug info. 1421 /* First try in the same directory as the original file. */ 1422 strcpy (debugfile, dir); 1423 strcat (debugfile, basename); It comes from this check. We don't even compare the name (which is likely to be the same, but in the case of GLIBC's symlinks, isn't). Should we use stat to reject CRC'ing the file itself? I know there's a catch with inode number checks on some filesystems (Windows), but ld has some code for this. -- Daniel Jacobowitz CodeSourcery