Re: [PATCH] Return argv0-symlink.exp early if gdb can't load symlink

[Pedro Alves <palves@redhat.com>]

On 04/02/2014 09:56 AM, Yao Qi wrote:
> On 04/02/2014 04:43 PM, Yao Qi wrote:
>> We run argv0-symlink.exp on mingw32 host, and see the following error
>> in gdb.log
>>
>> (gdb) file argv0-symlink-filelink^M
>> "argv0-symlink-filelink": not in executable format: File format not recognized
>> (gdb) ERROR: Couldn't load argv0-symlink-filelink into arm-none-eabi-gdb.
>>
>> the rest of the test don't have to run.
> 
> Forget to mention that we run mingw32 toolchain test in cygwin, so
> symbol link can be created (via command ln) successfully, but it is not
> a real symlink, AFAIK, so this guard in argv0-symlink.exp below doesn't
> return,

There are multiple tests in the tree that do "ln -s".  All others
are run on the build, not host though, though I suspect that's
a bug.  E.g., does gdb.base/sepdebug.exp pass on your setup?

Running mingw32 gdb+Cygwin like that it's really as if testing
under MSYS instead of Cygwin.  I think MSYS's solution for this
is that "ln -s" copies the file instead of actually creating a
symlink.

(people were trying to make MSYS v2 be just a mode of mainline
Cygwin, instead of a fork as v1 was, but I don't know the status
of that).

This reminds of me AC_PROG_LN_S / LN_S, though that's useless
here, for being a build, not host test.  It ends up being the
same as "ln -s" under MSYS, as as_ln_s ends up as set as
"cp -p" on systems that don't support symlinks (see 'as_ln_s' in
gdb's generated configure, for example).

But in our case, I'm not sure we actually want to make copies
instead of symlinks.  It might be better to actually fail
creating the symlinks, and then let the callers decide what to
do (skip the test, or copy the file themselves).

In case you're running the tests on a Windows system that
supports it, did you try just setting winsymlinks:native in your
CYGWIN?  Things then should work IIUC.  If GDB can't load
native Windows symlinks, then that sounds like a real GDB
bug to me.

For the case one is running tests on a Windows system that
does _not_ support native Windows symlinks, then I think
the solution should revolve around not hardcoding "ln -s"
in the tests.

We would add a new gdb_ln_s procedure that takes care of
creating a symlink on thte host, and would make the tests
use that instead of hardcoding "ln -s".
We could clone AC_PROG_LN_S's tests, while making then run
on the host, or start simple, and just make it do "ln -s",
and check the result.

In any case, the procedure would still detect Cygwin's "ln -s" as
functional.  To address that you'd need to make sure Cygwin's "ln" is
out of the PATH (or do "ln -s /bin/false /somewhere/ln", and make
sure /somewhere/ln appears before the real ln in PATH.)

Alternatively to playing with PATH, the host board file can
override gdb_ln_s, tuning it for the host system (or the command
the procedure invokes is specified in a variable in the board
file instead, but that's just an implementation detail).

> 
> set status [remote_exec host "ln -sf . [standard_output_file $dirlink]"]
> if {[lindex $status 0] != 0} {
>     unsupported "$test (host does not support symbolic links)"
>     return 0
> }
> 
> Looks native windows symlinks are created on some versions of windows
> with some features turned on, so we can't skip this test by checking
> triplet of host.
> http://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks

-- 
Pedro Alves