This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
What happended to sepdebug.exp?
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: gdb at sourceware dot org
- Date: Sun, 9 Sep 2007 23:49:04 +0200 (CEST)
- Subject: What happended to sepdebug.exp?
On OpenBSD I'm seeing the following testsuite regression/freakout:
PASS: gdb.base/sepdebug.exp: next over recursive call
PASS: gdb.base/sepdebug.exp: backtrace from factorial(5.1)
PASS: gdb.base/sepdebug.exp: continue until exit at recursive next test
-PASS: gdb.base/sepdebug.exp: set separate debug location
-PASS: gdb.base/sepdebug.exp: breakpoint function, optimized file
-PASS: gdb.base/sepdebug.exp: breakpoint small function, optimized file
-PASS: gdb.base/sepdebug.exp: run until function breakpoint, optimized file
-PASS: gdb.base/sepdebug.exp: run until breakpoint set at small function, optimized file
+PASS: debuglink: set separate debug location
+PASS: debuglink: breakpoint function, optimized file
+PASS: debuglink: breakpoint small function, optimized file
+PASS: debuglink: run until function breakpoint, optimized file
+PASS: debuglink: run until breakpoint set at small function, optimized file
+ERROR: tcl error sourcing ../../../../src/gdb/gdb/testsuite/gdb.base/sepdebug.exp.
+ERROR: objcopy: there are no sections to be copied!
+ while executing
+"exec objcopy -j .note.gnu.build-id -O binary $exec $tmp"
+ (procedure "build_id_debug_filename_get" line 3)
+ invoked from within
+"build_id_debug_filename_get $binfile"
+ invoked from within
+"set build_id_debug_filename [build_id_debug_filename_get $binfile]"
+ (file "../../../../src/gdb/gdb/testsuite/gdb.base/sepdebug.exp" line 956)
+ invoked from within
+"source ../../../../src/gdb/gdb/testsuite/gdb.base/sepdebug.exp"
+"exec objcopy -j .note.gnu.build-id -O binary $exec $tmp"
+ (procedure "build_id_debug_filename_get" line 3)
+ invoked from within
+"build_id_debug_filename_get $binfile"
+ invoked from within
+"set build_id_debug_filename [build_id_debug_filename_get $binfile]"
+ (file "../../../../src/gdb/gdb/testsuite/gdb.base/sepdebug.exp" line 956)
+ invoked from within
+"source ../../../../src/gdb/gdb/testsuite/gdb.base/sepdebug.exp"
+ ("uplevel" body line 1)
+ invoked from within
+"uplevel #0 source ../../../../src/gdb/gdb/testsuite/gdb.base/sepdebug.exp"
+ invoked from within
+"catch "uplevel #0 source $test_file_name""
Now probably the OpenBSD toolchain doesn't support the build ID stuff
completely, but.
1. The "PASS: debuglink: XXXX" look wrong to me, do people see those
on other systems too?
2. This test should fail a bit more graceful if the necessary
toolchain support is missing.
The diff below addresses the second issue. Does it look reasonable?
Mark
Index: ChangeLog
from Mark Kettenis <kettenis@gnu.org>
* lib/gdb.exp (build_id_debug_filename_get): Improve check for
build-id.
Index: lib/gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.87
diff -u -p -r1.87 gdb.exp
--- lib/gdb.exp 1 Sep 2007 08:16:16 -0000 1.87
+++ lib/gdb.exp 9 Sep 2007 21:46:57 -0000
@@ -382,7 +382,7 @@ proc runto { function args } {
# the "at foo.c:36" output we get with -g.
# the "in func" output we get without -g.
- gdb_expect 30 {
+ gdb_expect 60 {
-re "Break.* at .*:$decimal.*$gdb_prompt $" {
return 1
}
@@ -2487,7 +2487,14 @@ proc separate_debug_filename { exec } {
# Return "" if no build-id found.
proc build_id_debug_filename_get { exec } {
set tmp "${exec}-tmp"
- exec objcopy -j .note.gnu.build-id -O binary $exec $tmp
+ set objcopy_program [transform objcopy]
+
+ set result [catch "exec $objcopy_program -j .note.gnu.build-id -O binary $exec $tmp" output]
+ verbose "result is $result"
+ verbose "output is $output"
+ if {$result == 1} {
+ return ""
+ }
set fi [open $tmp]
# Skip the NOTE header.
read $fi 16