Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFA: handle "MiniDebuginfo" section
Date: Tue, 13 Nov 2012 12:56:00 -0000	[thread overview]
Message-ID: <50A2437D.7080301@redhat.com> (raw)
In-Reply-To: <87haoycvqi.fsf@fleche.redhat.com>

On 11/09/2012 09:27 PM, Tom Tromey wrote:
> Pedro> Seems like this won't work with remote hosts as is.  Can we make
> Pedro> it use "remote_file host delete", "remote_spawn host", etc.?  If
> Pedro> not, perhaps just bail early if [is_remote host].
> 
> FWIW, I took a stab at this, using the appended patch.
> However, I could not get it to work.  I always get an error:
> 
> ERROR: bad spawn_id (process died earlier?)
>     while executing
> "expect {
> 	-i $spawn_id -timeout $timeout -re ".+" {
> 	    append output $expect_out(buffer)
> 	    if { [string length $output] < 512000 } {
> 		exp_contin..."
>     (procedure "local_exec" line 94)
>     invoked from within
> [...]
> 
> 
> I don't know if this is my bug, or dejagnu's, or expect's -- but I
> couldn't find a way to work around it.

I did some experimenting, and found that the problem is in args
passed to remote_exec.  Specifically, leaving input empty,
while specifying an output at the same time.  Using "/dev/null" instead works.
See patch below.  I wondered if /dev/null would work on Windows, so I
did a google search for remote_exec and /dev/null, and found that
returns hits in the binutils testsuite,

...
testsuite/lib/ld-lib.exp:70:    remote_exec host "$ld --version" "" "/dev/null" "ld.version"
testsuite/lib/ld-lib.exp:91:    set status [remote_exec host [concat sh -c [list "$prog $command 2>&1"]] "" "/dev/null" "ld.tmp"]
testsuite/lib/ld-lib.exp:299:    set status [remote_exec host [concat sh -c [list "$cc $flags $ccflags -c $source -o $object 2>&1"]] "" "/dev/null" "ld.tmp"]
...

so that does sound like the way to go.

In sum,

OK:
 remote_exec host program "" "/dev/null" "output"
Not OK:
 remote_exec host program "" "" "output"

I see one FAIL though.  Exactly the same with your original patch that
didn't do any remote_exec stuff, and with the fixed remote_exec stuff:

(gdb) kill
The program is not being run.
(gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.test
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.test...(no debugging symbols found)...done.
(gdb) p debugdata_function
No symbol table is loaded.  Use the "file" command.
(gdb) FAIL: gdb.dwarf2/dw2-gnu-debugdata.exp: have symtab
testcase ../../../src/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.exp completed in 1 seconds

I haven't tried your new updated patch yet.


 gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.exp |   21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.exp b/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.exp
index 85391e6..8aaf97f 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-gnu-debugdata.exp
@@ -24,19 +24,24 @@ if [build_executable ${testfile}.exp $testfile] {
     return -1
 }

-source /tmp/remote.exp
-
-set pipeline_counter 0
-
 # A wrapper for 'remote_exec host' that passes or fails a test.
 # Returns 0 if all went well, nonzero on failure.
 # TEST is the name of the test, other arguments are as for
 # remote_exec.
 proc run {test program args} {
     verbose -log "cmdline is remote_exec host $program $args"
-    set result [eval remote_exec host [list $program] $args]
+
+    # "" -> "/dev/null"
+    if { [llength $args] > 1 } {
+	if {[lindex $args 1] == ""} {
+	    set args [lreplace $args 1 1 "/dev/null"]
+	}
+    }
+
+    set result [eval remote_exec host $program $args]
+
     verbose "result is $result"
-    lassign $result output status
+    lassign $result status output
     if {$status == 0} {
 	pass $test
 	return 0
@@ -54,7 +59,7 @@ proc run {test program args} {
 # Each program in the pipeline takes its input from the previous
 # program's output.
 proc pipeline {test args} {
-    global pipeline_counter
+    set pipeline_counter 0

     set input_file {}
     foreach arglist $args {
@@ -68,7 +73,7 @@ proc pipeline {test args} {
 	    set output pipe.[pid].$pipeline_counter
 	    incr pipeline_counter
 	}
-	verbose -log "cooked args are [list $program $arguments $input $output]"
+	verbose -log "cooked args are: $program [list $arguments $input $output]"

 	if {[run "$test - invoke $program" $program $arguments \
 		 $input $output]} {


  reply	other threads:[~2012-11-13 12:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-09 17:33 Tom Tromey
2012-11-09 18:07 ` Eli Zaretskii
2012-11-09 18:13 ` Pedro Alves
2012-11-09 21:28   ` Tom Tromey
2012-11-13 12:56     ` Pedro Alves [this message]
2012-11-13 15:26       ` Pedro Alves
2012-11-13 18:32       ` Tom Tromey
2012-11-09 18:23 ` Joel Brobecker
2012-11-09 18:53   ` Pedro Alves
2012-11-09 19:13   ` Tom Tromey
2012-11-12 16:04   ` Tom Tromey
2012-11-12 17:04     ` Joel Brobecker
2012-11-12 18:24       ` Tom Tromey
2012-11-12 16:28 ` Tom Tromey
2012-11-13 18:36   ` Tom Tromey
2012-11-13 18:42     ` Eli Zaretskii
2012-11-13 19:12     ` Pedro Alves
2012-11-13 20:57       ` Tom Tromey
2012-11-14 16:13         ` Tom Tromey
2012-11-14 16:19           ` Pedro Alves
2012-11-14 16:59             ` Tom Tromey
2012-11-14 19:37           ` Doug Evans
2012-11-14 22:12             ` Joel Brobecker
2012-11-15 11:18             ` Pedro Alves
2012-11-16 19:51               ` Tom Tromey
2012-11-19 14:41                 ` Pedro Alves
2012-11-26 19:21                   ` Tom Tromey
2012-11-26 22:24                     ` Andrew Pinski
2012-11-27  2:23                       ` Tom Tromey
2012-11-29 19:19                     ` Ulrich Weigand
2012-11-29 19:23                       ` Tom Tromey
2012-11-29 19:33                         ` Ulrich Weigand
2012-11-29 20:51                           ` Tom Tromey
2012-11-30 14:05                             ` Ulrich Weigand
2012-11-30 20:59                               ` Tom Tromey
2012-12-05 17:09                                 ` Ulrich Weigand
2012-12-11 16:42                     ` Yufeng Zhang
2012-11-16 20:04             ` Tom Tromey
2012-11-12 21:26 ` Doug Evans
2012-11-13 17:43   ` Tom Tromey
2012-11-13 15:44 ` Jan Kratochvil
2012-11-13 18:34   ` Tom Tromey

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=50A2437D.7080301@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /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