Which board testsuite configuration file should I run (target: ARM Embedded platform (gdbserver); host: GNU/Linux)

[Simon Marchi]

On 2018-01-29 08:15, Christian Schwarzgruber wrote:
> Hey!
> 
> Lately I wanted to run the gdb testsuite in GDB 8.0.1 to see if the 
> same
> assert I came across gets triggert with the teststuite as well.
> 
> The target is an Embedded ARM platform the host is a GNU/Linux OS.
> After some reading I ended up with this line.
> $ cd gdb/testsuite && make site.exp && runtest
> --target_board=remote-stdio-gdbserver REMOTE_USERNAME=root
> REMOTE_HOSTNAME=192.168.31.7
> 
> The testsuite did run fine, although it did not trigger the assert. So 
> I
> thought, I may give the latest weekly snapshot a try, which was at that
> date gdb-weekly-8.1.50.20180116.tar.xz. After downloading and compiling 
> for
> the ARM platform. I wanted to run the testsuite again, but without any
> luck. After some investigation I figured out that the test programs did 
> not
> get downloaded to the target platform, in addition I had to set the
> REMOTE_TMPDIR now as well.
> 
> $ cd gdb/testsuite && make site.exp && runtest
> --target_board=remote-stdio-gdbserver REMOTE_USERNAME=root
> REMOTE_HOSTNAME=192.168.31.7 REMOTE_TMPDIR=/tmp
> 
> After grepping through the git history. I added back these lines below 
> to
> remote-stdio-gdbserver.ex. The testsuite did now run fine again. (I 
> have
> slightly modified ${board}_download from 739b3f1d8f)
> 
> proc ${board}_download { board host dest } {
>     return [standard_download $board $host "$dest"]
> }
> 
> proc ${board}_upload {dest srcfile args} {
>     return [standard_upload $dest $srcfile $args]
> }
> 
> proc ${board}_file { dest op args } {
>     if { $op == "delete" } {
>     return [remote_exec [get_remote_login] "rm -f $args"]
>     }
>     return [eval [list standard_file $dest $op] $args]
> }
> 
> My question is, is this a regression or did I use the wrong board
> configuration file.
> 
> BTW, the assert triggered in thread.c from GDB 8.0.1 did go away in
> gdb-weekly-8.1.50.20180116.tar.xz. However, a different assert gets now
> triggerd in target.c.
> 
> Thank you!
> 
> Christian

Hi Christian,

I just tried the configuration (though with two x86 machines) and I 
indeed see that the files don't get downloaded to the target machine.  
The remote-stdio-gdbserver board inherits from stdio-gdbserver-base, 
which inherits from gdbserver-base.  In gdbserver-base, the 
${board}_download procedure is defined as:

proc ${board}_download { board host dest } {
     # We pass DEST in standard_output_file, regardless of whether it is 
absolute
     # or relative, because we don't want the tests to be able to write 
outside
     # their standard output directory.
     set dest [standard_output_file $dest]

     file copy -force $host $dest

     return $dest
}

This version of _download just copies the file on the local file system 
so it can't work if the file needs to be copied to a remote system.  
That's why overriding ${board}_download made it work for you.  It does 
seem like a bug to me, since remote-stdio-gdbserver ends up with a 
version of _download not suitable for it.

Simon