From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7453 invoked by alias); 2 Apr 2014 10:47:12 -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 7439 invoked by uid 89); 2 Apr 2014 10:47:11 -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 10:47:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s32Al7JE028846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Apr 2014 06:47:07 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s32Al4td013379; Wed, 2 Apr 2014 06:47:06 -0400 Message-ID: <533BEAA8.4080100@redhat.com> Date: Wed, 02 Apr 2014 10:47: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> In-Reply-To: <533BD0D5.4000408@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00024.txt.bz2 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