Message ID | 1521043903-18837-4-git-send-email-arnez@linux.vnet.ibm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 9294 invoked by alias); 14 Mar 2018 16:13:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 8586 invoked by uid 89); 14 Mar 2018 16:13:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= 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, 14 Mar 2018 16:13:55 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2EGC0Tf125926 for <gdb-patches@sourceware.org>; Wed, 14 Mar 2018 12:13:54 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2gq6y38c4m-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for <gdb-patches@sourceware.org>; Wed, 14 Mar 2018 12:13:53 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <gdb-patches@sourceware.org> from <arnez@linux.vnet.ibm.com>; Wed, 14 Mar 2018 16:13:51 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 14 Mar 2018 16:13:50 -0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w2EGDn9a62193900 for <gdb-patches@sourceware.org>; Wed, 14 Mar 2018 16:13:49 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7891D42042 for <gdb-patches@sourceware.org>; Wed, 14 Mar 2018 16:06:04 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 572CA4203F for <gdb-patches@sourceware.org>; Wed, 14 Mar 2018 16:06:04 +0000 (GMT) Received: from oc1027705133.ibm.com (unknown [9.152.212.144]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP for <gdb-patches@sourceware.org>; Wed, 14 Mar 2018 16:06:04 +0000 (GMT) From: Andreas Arnez <arnez@linux.vnet.ibm.com> To: gdb-patches@sourceware.org Subject: [PATCH 3/3] Fix a FAIL in attach.exp under native-extended-gdbserver Date: Wed, 14 Mar 2018 17:11:03 +0100 In-Reply-To: <1521043903-18837-1-git-send-email-arnez@linux.vnet.ibm.com> References: <1521043903-18837-1-git-send-email-arnez@linux.vnet.ibm.com> X-TM-AS-GCONF: 00 x-cbid: 18031416-0020-0000-0000-000004047467 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18031416-0021-0000-0000-00004298793C Message-Id: <1521043903-18837-4-git-send-email-arnez@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-14_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803140183 X-IsSubscribed: yes |
Commit Message
Andreas Arnez
March 14, 2018, 4:11 p.m. UTC
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. gdb/testsuite/ChangeLog: * gdb.base/attach.exp: Accept the error message "don't know how to run" when not running on a native target. --- gdb/testsuite/gdb.base/attach.exp | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
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 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). Simon
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=<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
diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp index efec49e385..1651dc40a7 100644 --- a/gdb/testsuite/gdb.base/attach.exp +++ b/gdb/testsuite/gdb.base/attach.exp @@ -421,11 +421,18 @@ proc test_command_line_attach_run {} { send_gdb "y\n" + set cantrun 0 set test "run to main" gdb_test_multiple "" $test { -re "Temporary breakpoint .* main .*$gdb_prompt $" { pass $test } + -re "Don't know how to run..*$gdb_prompt $" { + set cantrun 1 + } + } + if { $cantrun && [gdb_is_target_native] } { + fail $test } # Get rid of the process