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

[Yao Qi]

On 04/02/2014 06:47 PM, Pedro Alves wrote:
> 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?

There is only one fail in gdb.base/sepdebug.exp, so I didn't think
about it much.  gdb.dwarf2/dwp-symlink.exp does "ln -s" on host,
but it is skipped in remote host because dwp files are not found.

> 
> 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).

Right, the case is intended to test symlink rather than a copy
of a file.

> 
> 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.

Yes, I tried that, and GDB still failed to load symlink.  However,
I didn't investigate native windows symlink is created or it is a
real GDB bug.  If we want to test GDB reading native windows
symlink, why don't we write code to create symlink via
CreateSymbolicLink
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa363878(v=vs.85).aspx)?

> 
> 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.

No idea how to detect such Windows system in procedure off hand.

> 
> 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).

The detection of "ln -s" looks complicated.  Supposing procedure
gdb_ln_s returns boolean indicating "ln -s" creates symlink
successfully or not, set environment variable CYGWIN to
winsymlinks:native and execute "ln -s foo bar", if status isn't zero,
return false.  Then, check whether a native windows symlink is created,
but it is unknown to me.

In short, we want to create a valid symlink and let GDB read it in in
argv0-symlink.exp.  If host is mingw, we can write a small program to
create native symlink via CreateSymbolicLink, otherwise use command
"ln -s" to create symlink.  When GDB reads symlink in and error
occurred, if host is mingw, report a fail because it is unexpected,
otherwise, otherwise, return early in argv0-symlink.exp.  WDYT?

-- 
Yao (齐尧)