[Bug testsuite/16947] New: Fail to compile test case when board file local-remote-host.exp is used

[Bug testsuite/16947] New: Fail to compile test case when board file local-remote-host.exp is used

[qiyao at gcc dot gnu.org]

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

            Bug ID: 16947
           Summary: Fail to compile test case when board file
                    local-remote-host.exp is used
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: qiyao at gcc dot gnu.org

$ make check RUNTESTFLAGS='--host_board=local-remote-host foll-exec.exp' 
...
Running ../../../../git/gdb/testsuite/gdb.base/foll-exec.exp ...                
gdb compile failed,
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/../../../../git/gdb/testsuite/gdb.base/foll-exec.c:
In function 'main':              
<command-line>:0:9: error: 'gdb' undeclared (first use in this function)        
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/../../../../git/gdb/testsuite/gdb.base/foll-exec.c:20:11:
note: in expansion of macro 'BASEDIR'          
   execlp (BASEDIR "/execd-prog",                                               
           ^                                                                    
<command-line>:0:9: note: each undeclared identifier is reported only once for
each function it appears in                                                    
/home/yao/Source/gnu/gdb/build-git/x86/gdb/testsuite/../../../../git/gdb/testsuite/gdb.base/foll-exec.c:20:11:
note: in expansion of macro 'BASEDIR'          
   execlp (BASEDIR "/execd-prog",

Looks macro BASEDIR isn't replaced successfully.

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

[Bug testsuite/16947] Fail to compile test case when board file local-remote-host.exp is used

[qiyao at gcc dot gnu.org]

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

--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> ---
gdb.base/unload.exp, gdb.base/checkpoint.exp, gdb.base/foll-vfork.exp,
gdb.base/watchpoint-solib.exp and gdb.dwarf2/dw2-dir-file-name.exp have the
same problem.

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

[Bug testsuite/16947] Fail to compile test case when board file local-remote-host.exp is used

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Let's for a moment take this out of the dejagnu context.

This is a minimal test-case:
...
$ cat test.c
#include <stdio.h>

const char * s = S;

int
main (void)
{
  printf ("S: '%s'\n", s);

  return 0;
}
...

When using -DS=foo, we run into the problem that there are no quotes:
...
$ gcc -DS=foo test.c && ./a.out
<command-line>:0:3: error: ‘foo’ undeclared here (not in a function); did you
mean ‘feof’?
test.c:3:18: note: in expansion of macro ‘S’
 const char * s = S;
...               ^

There's a simple way to fix this (
https://gcc.gnu.org/onlinedocs/cpp/Stringizing.html ):
...
+#define STR(s) #s
+#define XSTR(s) STR (s)

-const char * s = S;
+const char * s = XSTR (S);
...
with which we have:
...
$ gcc -DS=foo test.c && ./a.out
S: 'foo'
...

That however breaks down when using names that have parts that are defined as
macros:
...
$ gcc -DS=/unix/is/number/one test.c && ./a.out
S: '/1/is/number/one'
...
See for instance commit 250e8e0d7fe ("[gdb/testsuite] Fix dwo path in
fission-*.S").

OK, so let's drop the stringizing patch, and try escaping instead:
...
$ gcc -DS=\"foo\" test.c && ./a.out
S: 'foo'
...
Well, that works.


Now lets try to do that through ssh:
...
$ ssh localhost "gcc -DS=\"foo\" test.c && ./a.out"
<command-line>:0:3: error: ‘foo’ undeclared here (not in a function); did you
mean ‘feof’?
test.c:3:18: note: in expansion of macro ‘S’
 const char * s = S;
                  ^
...

And so we arrive at:
...
$ ssh localhost "gcc -DS=\\\"foo\\\" test.c && ./a.out"
S: 'foo'
...

If we take the arguments passing of ssh out of the equation by using a command
file, we run into the same problem:
...
$ echo "gcc -DS=\"foo\" test.c && ./a.out" > cmd.sh; ssh localhost bash
./cmd.sh
<command-line>:0:3: error: ‘foo’ undeclared here (not in a function); did you
mean ‘feof’?
test.c:3:18: note: in expansion of macro ‘S’
 const char * s = S;
                  ^
...
because:
...
$ cat cmd.sh 
gcc -DS="foo" test.c && ./a.out
...

So, again the same fix:
...
$ echo "gcc -DS=\\\"foo\\\" test.c && ./a.out" > cmd.sh; ssh localhost bash
./cmd.sh
S: 'foo'
...

A benefit of this approach though is that it's consistent: we run into the same
problems with and without ssh:
...
$ bash ./cmd.sh
S: 'foo'
...

As for the test-case mentioned, foll-exec.exp, it was fixed by commit
31d913c7e4e ("[testsuite] Remove BASEDIR"), which uses a different mechanism
and avoids quoting all-together: it uses argv[0] to determine the basedir of
the target exec.

So, let's try using argument passing:
...
$ cat test.c
#include <stdio.h>

int
main (int argc, const char *argv[])
{
  const char *s = argv[1];
  printf ("S: '%s'\n", s);

  return 0;
}
$ gcc test.c && ./a.out foo
S: 'foo'
$ ssh localhost "gcc test.c && ./a.out foo"
S: 'foo'
...
That seems to work well.

I've also seen a solution in one test-case (can't remember which atm) which
uses gdb's ability to set a variable in the target exec:
...
$ gcc -g test.c; ./a.out; gdb -q -batch ./a.out -ex start -ex "set var
s=\"foo\"" -ex continue 
S: '(null)'
Temporary breakpoint 1 at 0x40050b: file test.c, line 8.

Temporary breakpoint 1, main () at test.c:8
8         printf ("S: '%s'\n", s);
S: 'foo'
[Inferior 1 (process 10855) exited normally]
...
But that only works when there's debug info, and may need volatile to work in
presence of optimization.  [ Note that the escaping is only there because we
use -ex, for interactive gdb, we'd just use (gdb) set var s="foo". ]

Still, it does work around the escaping issue for interactive gdb over ssh:
...
$ ssh localhost gdb -q ./a.out
Reading symbols from ./a.out...
(gdb) start
Temporary breakpoint 1 at 0x40050b: file test.c, line 8.
Starting program: /home/vries/a.out 
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.31-150300.41.1.x86_64

Temporary breakpoint 1, main () at test.c:8
8         printf ("S: '%s'\n", s);
(gdb) set var s="foo"
(gdb) c
Continuing.
S: 'foo'
[Inferior 1 (process 11253) exited normally]
(gdb) 
...

But ultimately, we run into the same problem with '$ORIGIN' in gdb_compile, and
this:
...
           if { [is_remote host] } {
               lappend new_options "ldflags=-Wl,-rpath,\\\\\$ORIGIN"
           } else {
               lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN"
           }
...
seems to be the only fix available.

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

[Bug testsuite/16947] Fail to compile test case when board file local-remote-host.exp is used

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Note btw that the originally mentioned test-case foll-exec.exp doesn't work
with remote target, and needs:
...
diff --git a/gdb/testsuite/gdb.base/foll-exec.exp
b/gdb/testsuite/gdb.base/foll-exec.exp
index 8cddfa52c3b..a3d1a8781e9 100644
--- a/gdb/testsuite/gdb.base/foll-exec.exp
+++ b/gdb/testsuite/gdb.base/foll-exec.exp
@@ -36,6 +36,10 @@ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile2}"
"${binfile2}" 
executable $c
      return -1
 }

+if { [is_remote target] } {
+    gdb_remote_download target $binfile2
+}
+
 if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable
$compile_options]
 != "" } {
      untested "failed to compile"
      return -1
...
to get $binfile2 alongside $binfile on the remote target.

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

[Bug testsuite/16947] Fail to compile test case when board file local-remote-host.exp is used

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> But ultimately, we run into the same problem with '$ORIGIN' in gdb_compile,
> and this:
> ...
>            if { [is_remote host] } {
>                lappend new_options "ldflags=-Wl,-rpath,\\\\\$ORIGIN"
>            } else {
>                lappend new_options "ldflags=-Wl,-rpath,\\\$ORIGIN"
>            }
> ...
> seems to be the only fix available.


And this is a way to fix this at board level:
...
diff --git a/gdb/testsuite/boards/local-remote-host.exp
b/gdb/testsuite/boards/local-remote
-host.exp
index fc87dd48014..36f152b8749 100644
--- a/gdb/testsuite/boards/local-remote-host.exp
+++ b/gdb/testsuite/boards/local-remote-host.exp
@@ -68,4 +68,10 @@ proc ${board}_spawn { board cmd } {
     return $spawn_id
 }

+proc ${board}_exec { boardname program pargs inp outp } {
+    set program [regsub -all {"} $program {\\\\"}]
+    set program [regsub -all {\\\$} $program {\\\\$}]
+    return [rsh_exec $boardname $program $pargs $inp $outp]
+}
+
 set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\""
...

This makes gdb.base/print-file-var.exp pass, which uses both $ORIGIN and
SHLIB_NAME.

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