From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105667 invoked by alias); 11 Oct 2017 14:53:18 -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 105654 invoked by uid 89); 11 Oct 2017 14:53:17 -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,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=tbh, TBH X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Oct 2017 14:53:16 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9BEqCML106043 for ; Wed, 11 Oct 2017 10:53:15 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 2dhj86mmhw-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 11 Oct 2017 10:53:14 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 11 Oct 2017 15:52:27 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 11 Oct 2017 15:52:26 +0100 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v9BEqPNJ19136620; Wed, 11 Oct 2017 14:52:25 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3337011C05B; Wed, 11 Oct 2017 15:47:59 +0100 (BST) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1365A11C04A; Wed, 11 Oct 2017 15:47:59 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.164]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Wed, 11 Oct 2017 15:47:59 +0100 (BST) From: Andreas Arnez To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] GDB test suite: Add helper for locating core files References: <1505760152-28775-1-git-send-email-arnez@linux.vnet.ibm.com> <1505760152-28775-2-git-send-email-arnez@linux.vnet.ibm.com> <20171007094545.1bba5c51@pinnacle.lan> <20171011011733.19b3658c@pinnacle.lan> Date: Wed, 11 Oct 2017 14:53:00 -0000 In-Reply-To: <20171011011733.19b3658c@pinnacle.lan> (Kevin Buettner's message of "Wed, 11 Oct 2017 01:17:33 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17101114-0008-0000-0000-0000049ECDF9 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101114-0009-0000-0000-00001E30DBBD Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-11_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710110206 X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00293.txt.bz2 On Wed, Oct 11 2017, Kevin Buettner wrote: > On Mon, 09 Oct 2017 20:46:21 +0200 > Andreas Arnez wrote: > >> > Instead, several warnings are now printed instead: >> > >> > WARNING: Can not generate core dump on remote target. >> >> These warnings are newly introduced by the patch. > > Yes, I saw that. > >> They are meant to >> improve diagnostics when someone attempts to run the tests on a "real" >> remote target. I wanted to clearly document the fact that this is >> unsupported (and always was). Also, by documenting this restriction, >> maybe someone feels encouraged to lift it ;-) > > In the distant past, I used to run the testsuite against resource > constrained linux machines often of a different architecture from the > host I was running the tests from. These machines would run gdbserver > built for that architecture. OK, in that scenario, core file test cases would need to be roughly executed in four steps: (1) Build executable. (2) Run executable on the remote machine. (3) Transfer core dump to the local host. (4) Start GDB on the local host. AFAIK, steps (2) and (3) have not been implemented for the GDB test suite so far. > Now, I don't recall whether corefile support in the testsuite actually > worked for those targets, but it at least seems possible due to the > various invocations of remote_exec which are present (prior to your > patch). Fairly unlikely. See, for instance, the beginning of corefile.exp: # are we on a target board if ![isnative] then { return } A check like this appears in all core dump test cases. Also note that the core_find command in gdb.exp uses expect's "system" command for invoking the executable: catch "system \"(cd ${coredir}; ulimit -c unlimited; ${binfile} ${arg}; true) >/dev/null 2>&1\"" Which means that this command line will be executed on the local machine and will fail in a remote setup. But you're right that there were remote_exec invocations; mostly for file handling such as: remote_exec build "mv $i $destcore" remote_exec build "mv $corefile $destcore" remote_exec build "rmdir $coredir" TBH, I don't quite understand their intention. In a native remote setup, "build" is the remote machine. Moving the core file around there doesn't make it appear on the local machine. And in a cross remote setup, "build" is the local machine, whereas the core dump should be generated on the remote machine. So I think these commands only work if host == build == target. Since I found this too misleading, I replaced them by local commands. > Do you think you could restore those calls to remote_exec in your > patch? Or do you know for a fact that they do not work? I'm pretty sure they don't. Thus I wanted to document this restriction more clearly. -- Andreas