From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18749 invoked by alias); 2 Apr 2014 16:44:01 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18740 invoked by uid 89); 2 Apr 2014 16:44:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Apr 2014 16:43:59 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s32Ghig3014872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Apr 2014 12:43:45 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s32GhhVb012248; Wed, 2 Apr 2014 12:43:43 -0400 Message-ID: <533C3E3E.50701@redhat.com> Date: Wed, 02 Apr 2014 16:44:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Return argv0-symlink.exp early if gdb can't load symlink References: <1396428218-31822-1-git-send-email-yao@codesourcery.com> <533BD0D5.4000408@codesourcery.com> <533BEAA8.4080100@redhat.com> <533C18DA.3000307@codesourcery.com> In-Reply-To: <533C18DA.3000307@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00031.txt.bz2 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