[Bug testsuite/29697] New: [gdb/testsuite, local-remote-host] FAIL: gdb.base/callfuncs.exp: noproto: p ((int (*) ()) t_float_values2)(3.14159,float_val2)

[Bug testsuite/29697] New: [gdb/testsuite, local-remote-host] FAIL: gdb.base/callfuncs.exp: noproto: p ((int (*) ()) t_float_values2)(3.14159,float_val2)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29697

            Bug ID: 29697
           Summary: [gdb/testsuite, local-remote-host] FAIL:
                    gdb.base/callfuncs.exp: noproto: p ((int (*) ())
                    t_float_values2)(3.14159,float_val2)
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With host board local-remote-host.exp and test-case gdb.base/callfuncs.exp, I
run into:
...
(gdb) PASS: gdb.base/callfuncs.exp: noproto: p
t_float_values2(3.14159,float_val2)
p ((int (*) ()) t_float_values2)(3.14159,float_val2)^M
$30 = 0^M
(gdb) FAIL: gdb.base/callfuncs.exp: noproto: p ((int (*) ())
t_float_values2)(3.14159,float_val2)
...

It took me a while to realize that the problem is that there are two
prepare_for_testing calls, writing to the same exec, and somehow the second has
no effect.

In other words, we're seeing the effect of having additional_flags=-DPROTOTYPES
in both cases.

This can easily be solved with something like:
...
diff --git a/gdb/testsuite/gdb.base/callfuncs.exp
b/gdb/testsuite/gdb.base/callfuncs.exp
index 44289eebc8b..403f127bfe8 100644
--- a/gdb/testsuite/gdb.base/callfuncs.exp
+++ b/gdb/testsuite/gdb.base/callfuncs.exp
@@ -540,11 +540,11 @@ proc perform_all_tests {prototypes} {

 # Perform all tests with and without function prototypes.

-if { ![prepare_for_testing "failed to prepare" $testfile $srcfile
"$compile_flags additio
nal_flags=-DPROTOTYPES"] } {
+if { ![prepare_for_testing "failed to prepare" $testfile-proto $srcfile
"$compile_f
lags additional_flags=-DPROTOTYPES"] } {
     perform_all_tests 1
 }

-if { ![prepare_for_testing "failed to prepare" $testfile $srcfile
"$compile_flags additio
nal_flags=-DNO_PROTOTYPES"] } {
+if { ![prepare_for_testing "failed to prepare" $testfile-noproto $srcfile
"$compile
_flags additional_flags=-DNO_PROTOTYPES"] } {
     with_test_prefix "noproto" {
        perform_all_tests 0
     }
...

It's a good idea to commit the patch, for reasons of having less confusion, as
other recent patches have done.

But the FAIL points to a problem with the file upload/download mechanism for
the host board.

I managed to make things work by removing ${board}_download from the host board
file, but that fills my home dir with temp files...

I tried other ways, but am possibly running into dejagnu bugs (using a.out as
hardcoded intermediate file for objects does not look sane to me), so this
looks like non-trivial to fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/29697] [gdb/testsuite, local-remote-host] FAIL: gdb.base/callfuncs.exp: noproto: p ((int (*) ()) t_float_values2)(3.14159,float_val2)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29697

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> I managed to make things work by removing ${board}_download from the host
> board file, but that fills my home dir with temp files...

And that breaks down once (test-case gdb.dwarf2/dwz.exp) you want to compile an
exec using -o ~/dwz, and you already have a directory ~/dwz.

I tried to get that test-case to work by removing ${board}_download and
${board}_file and using a REMOTE_HOST_DIR, like so:
...
if { ![info exists REMOTE_HOST_DIR] } {
    set REMOTE_HOST_DIR [file join [pwd] "remote-host-dir"]
}
if { ![file exists $REMOTE_HOST_DIR] } {
        file mkdir $REMOTE_HOST_DIR
}
set_board_info remotedir $REMOTE_HOST_DIR
...

I got to:
...
diff --git a/gdb/testsuite/boards/local-remote-host.exp
b/gdb/testsuite/boards/local-remote-host.exp
 # Like standard_spawn, but force pseudo-tty allocation, with 'ssh -t'.

 proc ${board}_spawn { board cmd } {
-    global board_info
+    global board_info REMOTE_HOST_DIR

     set remote [board_info $board hostname]
     set username [board_info $board username]
     set RSH [board_info $board rsh_prog]

-    spawn $RSH -t -l $username $remote $cmd
+    spawn $RSH -t -l $username $remote "cd $REMOTE_HOST_DIR; $cmd"
     set board_info($board,fileid) $spawn_id
     return $spawn_id
 }
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index e2cda30b95a..5f1f2fa0fbf 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -2099,7 +2099,15 @@ proc gdb_file_cmd { arg } {
     set gdb_file_cmd_debug_info "fail"

     if [is_remote host] {
-       set arg [remote_download host $arg]
+       set pre_arg $arg
+       set arg [remote_upload host $arg]
+       if { $arg == "" } {
+           perror "upload failed: remote_upload host $pre_arg"
+           return -1
+       }
+    }
+    if [is_remote target] {
+       set arg [remote_download target $arg]
        if { $arg == "" } {
            perror "download failed"
            return -1
@@ -6217,6 +6225,9 @@ proc standard_output_file_with_gdb_instance {basename} {
 # Return the name of a file in our standard temporary directory.

 proc standard_temp_file {basename} {
+    if { [is_remote host] } {
+       return $basename
+    }
     # Since a particular runtest invocation is only executing a single test
     # file at any given time, we can use the runtest pid to build the
     # path of the temp directory.
...

And I'm at the point that AFAICT, the gdb_default_target_compile_1 proc does:
...
    set compiler_flags $opts
    if {[is_remote host]} {
        remote_upload host [file tail $destfile] $destfile
        remote_file host delete [file tail $destfile]
    }
...
and the remote_upload fails, the exec is deleted and execution fails.

I seems that remote_upload indeed does not take remotedir into account.

-- 
You are receiving this mail because:
You are on the CC list for the bug.