From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9309 invoked by alias); 2 Apr 2014 14:06:23 -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 9294 invoked by uid 89); 2 Apr 2014 14:06:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Apr 2014 14:06:19 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WVLnz-00061N-HO from Yao_Qi@mentor.com ; Wed, 02 Apr 2014 07:06:15 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Apr 2014 07:06:15 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.2.247.3; Wed, 2 Apr 2014 07:06:14 -0700 Message-ID: <533C18DA.3000307@codesourcery.com> Date: Wed, 02 Apr 2014 14:06:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: 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> In-Reply-To: <533BEAA8.4080100@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00029.txt.bz2 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 (齐尧)