From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113714 invoked by alias); 25 Apr 2018 09:32:29 -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 112896 invoked by uid 89); 25 Apr 2018 09:31:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=mix, connecting, adapt, investigating X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Apr 2018 09:31:01 +0000 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3P9TL01058395 for ; Wed, 25 Apr 2018 05:30:49 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hjph19pts-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 25 Apr 2018 05:30:48 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Apr 2018 10:30:47 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Apr 2018 10:30:45 +0100 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w3P9Uj3R6750492; Wed, 25 Apr 2018 09:30:45 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6A6FA52043; Wed, 25 Apr 2018 09:21:23 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.186]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTPS id 4C1C55203F; Wed, 25 Apr 2018 09:21:23 +0100 (BST) From: Andreas Arnez To: Simon Marchi Cc: Subject: Re: [PATCH 3/3] Fix a FAIL in attach.exp under native-extended-gdbserver References: <1521043903-18837-1-git-send-email-arnez@linux.vnet.ibm.com> <1521043903-18837-4-git-send-email-arnez@linux.vnet.ibm.com> Date: Wed, 25 Apr 2018 09:32:00 -0000 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 18042509-0020-0000-0000-00000415977E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18042509-0021-0000-0000-000042AA0254 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-25_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1804250087 X-SW-Source: 2018-04/txt/msg00501.txt.bz2 Sorry for the delay... On Thu, Mar 15 2018, Simon Marchi wrote: > Hi Andreas, > > On 2018-03-14 12:11 PM, Andreas Arnez wrote: >> The attach.exp test case yields a FAIL with native-extended-gdbserver when >> trying to start a new process. This is because gdbserver does not support >> starting new processes. And since the gdbserver-base board file sets the >> GDB command line option -ex "set auto-connect-native-target off", the >> process is not started on the native target either. An error message >> results instead: >> >> Don't know how to run. Try "help target". >> >> Thus just accept this error when not running on a native target. > > It is not true that gdbserver can't run a new process, in fact it can in the > extended-remote protocol (as opposed to remote). Start gdbserver with: > > $ ./gdbserver/gdbserver --once --multi :1234 > > And > > $ ./gdb --data-directory=data-directory > (gdb) tar ext :1234 > (gdb) set remote exec-file /usr/bin/gnome-calculator > (gdb) run Thanks, you're right, of course. What really happens here is that attach.exp tries to start GDB with the command line options "--pid=" and "-ex start", using gdb_spawn_with_cmdline_opts. However, gdb_spawn_with_cmdline_opts is not overridden in native-extended-gdbserver.exp. Thus we just fire up GDB without setting an extended-remote target, and without having started gdbserver. And due to "auto-connect-native-target off", the "start" command then responds with the error message above. The test suite contains some other "gdb_spawn*" invocations, all having the same problem. To fix this, we should override these procs. > > Still, I first thought this test wouldn't be applicable to the extended-remote > protocol because I though you couldn't mix -p with connecting to a remote target > on startup, but it seems like this works: > > $ pidof gnome-calculator > 20001 > $ ./gdb --data-directory=data-directory -iex "tar ext :1234" -p 20001 -ex "set remote exec-file /usr/bin/gnome-calculator" -ex "start" > > So it might be possible to tweak the test case to adapt it to the extended-remote > protocol (add the -iex and "set remote exec-file" bits). Actually, after investigating this a bit further I wonder why "set remote exec-file" should even be necessary. In the native case GDB takes care of this for the user, if possible. And this is exactly what the test case tries to verify here. IMHO extended-remote should behave the same. So I think the current behavior is a usability bug and should be fixed. I've been working on some patches for this. I'll send them around later. -- Andreas