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

[Pedro Alves <palves at redhat dot com>]

On 04/02/2014 03:04 PM, Yao Qi wrote:
> On 04/02/2014 06:47 PM, Pedro Alves wrote:

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

It should actually be winsymlinks:nativestrict.  If you're testing
with a system/environment that doesn't actually support native
Windows symlinks, winsymlinks:native still falls back to
the default Cygwin symlinks when creating the native symlink fails.
nativestrict should make ln -s fail with an error instead.  Exactly
what you need.

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

Well, we could.  But setting winsymlinks:nativestrict should
give you that already.  Would be there be any benefit?

I'm failing to see what that gains you over winsymlinks:nativestrict,
which supposedly uses CreateSymbolicLink internally.  If there's
some benefit in writing our own, then we can just as well call the
resulting binary "ln.exe", and put that first in PATH, so it is picked
before Cygwin's.

Also, see http://cygwin.com/ml/cygwin/2011-04/msg00059.html here
for a tool that seems to do exactly that.

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

Which part?

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

I don't think this last part would be necessary.  Just use
winsymlinks:nativestrict instead?  Hmm, I was just thinking that
going this direction, you'd set it in your Cygwin environment
(that is, it would be a prerequisite for a cygwin x mingw kind of
setup like yours), not in the testsuite, but if it works, I
suppose we can do it from within gdb_ln_s.

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

I'm not sure I understood this last part.  If we have a tool that
creates symlinks, what's special about "host is mingw" then?

-- 
Pedro Alves