This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Recent separate debug file warning caused Debian regressions
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 2 Nov 2009 16:52:55 -0500
- Subject: Recent separate debug file warning caused Debian regressions
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