Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: gdb@sourceware.org
Subject: What happended to sepdebug.exp?
Date: Sun, 09 Sep 2007 21:55:00 -0000	[thread overview]
Message-ID: <200709092149.l89Ln4pK017577@brahms.sibelius.xs4all.nl> (raw)

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


             reply	other threads:[~2007-09-09 21:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-09 21:55 Mark Kettenis [this message]
2007-09-09 22:26 ` Daniel Jacobowitz
2007-09-10  9:49   ` Mark Kettenis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200709092149.l89Ln4pK017577@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox