Re: [PATCH 2/7] [gdb/testsuite] fix test gdb.base/print-file-var.exp for remote execution

[Tom de Vries <tdevries@suse.de>]

On 11/7/22 14:49, Ivan Tetyushkin wrote:
> Hi
> Yes, this patch fixes this test. However, it will not fix gdb.base/infcall-exec.exp from the patch 5/7 of this thread.

Hi Ivan,

thanks for reporting the problem and proposing fixes.

I went ahead and proposed a series, borrowing from yours, submitted here 
( https://sourceware.org/pipermail/gdb-patches/2022-November/193518.html ).

That test-case is also addressed there.

> As I can understand now, this test uses absolute paths for checking, but relative paths are used during compilation. We can change regexp itself and check only filename, but this could lead to false positive result.

The gdb.base/infcall-exec.exp test-case checks that an inferior function 
call which execs a new program is handled ok.  This is the main function 
of the test, and absolute vs relative paths is not an interesting aspect 
to check.

> Also, I thought these tests are created to work with absolute paths to ignore solib-search-path.

Maybe with local target, but for remote target we do use solib-search-path.

The overall problem is that there's no reliable way to do construct an 
absolute path on a remote target (which could f.i. be using \ instead of 
/ as path separator), or at least not an easy one.

We could do something like using remote_exec for "echo \"puts [file 
normalize .$file]\" | tclsh " but that requires tcl on the target.

So AFAIU, until dejagnu decided to support that natively, we just have 
to use the filenames as returned by remote_download.

On a different topic, do you have a copyright assignment?

Assuming you don't, with this submission you've probably used up your 
legally non-significant contribution amount, and for a new submission 
you'd need a copyright assignment (and unfortunately, it can take some 
time to get it done).

Thanks,
- Tom