[PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test

Andrew Burgess andrew.burgess@embecosm.com
Wed Feb 26 19:38:00 GMT 2020


* Shahab Vahedi <shahab.vahedi@gmail.com> [2020-02-07 15:59:50 +0100]:

> From: Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> Fileio test improperly checks if [is_remote host] and if it is, then
> uses file path that is safe to use on remote host.  But the problem is
> that [is_remote host] returns state of *this* host, not of the remote
> target, where filepaths actually matter.  This patch fixes that.
> 
> gdb/testsuite/ChangeLog:
> 2016-12-16  Anton Kolesov <Anton.Kolesov@synopsys.com>
> 
> 	* gdb.base/fileio.exp: Use "target" instead of "host".
> 
> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>

I don't really understand what the problem is here.

I'm probably just not understanding things, so please, correct let me
know where I'm going wrong, but I thought..

'is_remote host' - when this is true we're running dejagnu on machine
A, but actually running GDB on machine B.  GDB might then be talking
to a remote target on machine C, or maybe the test is also running on
machine B.

'is_remote target' - when this is true the thing being debugged is not
a child of the GDB process, it could be on a different machine, or it
could be gdbserver on the same machine, but it still seems to be
"remote" as far as GDB is concerned.

The fileio.exp test is I think testing remote fileio, not native
fileio, so when the test tries to open a file, it will be GDB that
actually opens the file for us.

So, if 'is_remote host' is false, then the files we open should be in
the local dejagnu file system, with the longer paths, while if
'is_remote host' is true, then I think the assumption is that GDB will
have been pushed over from the local tree to the remote host, and we
don't have the full file system hierarchy, so lets just use '.' as a
path prefix.

I don't think this test really makes much sense when 'is_remote
target' is false, otherwise we're just testing, what? That GDB doesn't
prevent the target doing IO?  And once upon a time we indeed made this
check, see commit 1bcdb42447a4a68d7c3837b3852db3fb632e379b, but this
was quickly changed in b257a0d30ab67df224f603c928127f2e653660b9 to a
check based on the target properties.

If I was going to guess, I'd guess your target can do real IO, into a
local file system?  I think, if this is the case you should be setting
'set_board_info gdb,nofileio 1' in your board file - but like I say,
this is just a guess.

Thanks,
Andrew



> ---
>  gdb/testsuite/gdb.base/fileio.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
> index 9735869e5190..627a685e118d 100644
> --- a/gdb/testsuite/gdb.base/fileio.exp
> +++ b/gdb/testsuite/gdb.base/fileio.exp
> @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] {
>  
>  standard_testfile
>  
> -if {[is_remote host]} {
> +if {[is_remote target]} {
>      set outdir .
>  } else {
>      set outdir [standard_output_file {}]
> -- 
> 2.25.0
> 



More information about the Gdb-patches mailing list