| Message ID | 20200207150003.8383-2-shahab.vahedi@gmail.com |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 81587 invoked by alias); 7 Feb 2020 15:01:03 -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 81373 invoked by uid 89); 7 Feb 2020 15:00:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=HContent-Transfer-Encoding:8bit X-HELO: mail-lj1-f195.google.com Received: from mail-lj1-f195.google.com (HELO mail-lj1-f195.google.com) (209.85.208.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Feb 2020 15:00:48 +0000 Received: by mail-lj1-f195.google.com with SMTP id o15so2463875ljg.6 for <gdb-patches@sourceware.org>; Fri, 07 Feb 2020 07:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ALQUAOJLgm1po56z2Aa5vM4NSCEKWE+wBK4xOEuM3Gc=; b=Bsw5JDGaHHaXHz/PaxcrW2Ydd20hGemIZERspYI9HZJYFlTSdD/3si/E3uHNvFrKsL 8H13LibAzPXFM97Rw74u8CY8dJ2fMNrQk4hSutra1q47N9hi/xPuHsci/9BvlgyDL2iz ebfqZTJ4lVRauEJrySL/NuvDL+YK+pIhSMwUBsL+jgJQtNbkLl44fMHn8jMyRu6kcZvK N2PMwJzKZtxrSuDx7RhDJw6cwJcRzBA+/tWJ1m/Aaua5DmkR2RureA6HxagRt1r7mR6U RWo+l9Ex3GZJljmN3A8HNe2jevKk2tzAEjBNj65Txv8JKwGAgf2u/lfROzS755qwj5wM DgWA== Return-Path: <shahab.vahedi@gmail.com> Received: from archie.internal.synopsys.com ([2a03:1b20:6:f011::2d]) by smtp.gmail.com with ESMTPSA id p136sm1184412lfa.8.2020.02.07.07.00.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2020 07:00:37 -0800 (PST) From: Shahab Vahedi <shahab.vahedi@gmail.com> To: gdb-patches@sourceware.org Cc: Shahab Vahedi <shahab@synopsys.com>, Shahab Vahedi <shahab.vahedi@gmail.com>, Francois Bedard <fbedard@synopsys.com>, Anton Kolesov <Anton.Kolesov@synopsys.com> Subject: [PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test Date: Fri, 7 Feb 2020 15:59:50 +0100 Message-Id: <20200207150003.8383-2-shahab.vahedi@gmail.com> In-Reply-To: <20200207150003.8383-1-shahab.vahedi@gmail.com> References: <20200207150003.8383-1-shahab.vahedi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit |
Commit Message
Shahab Vahedi
Feb. 7, 2020, 2:59 p.m. UTC
From: Anton Kolesov <Anton.Kolesov@synopsys.com> Fileio test improperly checks if [is_remote host] and if it is, then uses file path that is safe to use on remote host. But the problem is that [is_remote host] returns state of *this* host, not of the remote target, where filepaths actually matter. This patch fixes that. gdb/testsuite/ChangeLog: 2016-12-16 Anton Kolesov <Anton.Kolesov@synopsys.com> * gdb.base/fileio.exp: Use "target" instead of "host". Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> --- gdb/testsuite/gdb.base/fileio.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
Hi, On 2/7/20 11:59 AM, Shahab Vahedi wrote: > From: Anton Kolesov <Anton.Kolesov@synopsys.com> > > Fileio test improperly checks if [is_remote host] and if it is, then > uses file path that is safe to use on remote host. But the problem is > that [is_remote host] returns state of *this* host, not of the remote > target, where filepaths actually matter. This patch fixes that. Do you remember what that error was? I don't see any errors running on my end. Though the patch doesn't introduce new errors as well. Were you using a different board file that exercised gdbserver running on a remote host? I'm trying to understand what the problem is. > > gdb/testsuite/ChangeLog: > 2016-12-16 Anton Kolesov <Anton.Kolesov@synopsys.com> > > * gdb.base/fileio.exp: Use "target" instead of "host". > > Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> > --- > gdb/testsuite/gdb.base/fileio.exp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp > index 9735869e5190..627a685e118d 100644 > --- a/gdb/testsuite/gdb.base/fileio.exp > +++ b/gdb/testsuite/gdb.base/fileio.exp > @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] { > > standard_testfile > > -if {[is_remote host]} { > +if {[is_remote target]} { > set outdir . > } else { > set outdir [standard_output_file {}] >
On 2/11/20 8:29 AM, Luis Machado wrote: > Hi, > > On 2/7/20 11:59 AM, Shahab Vahedi wrote: >> From: Anton Kolesov <Anton.Kolesov@synopsys.com> >> >> Fileio test improperly checks if [is_remote host] and if it is, then >> uses file path that is safe to use on remote host. But the problem is >> that [is_remote host] returns state of *this* host, not of the remote >> target, where filepaths actually matter. This patch fixes that. > > Do you remember what that error was? I don't see any errors running on my end. Though the patch doesn't introduce new errors as well. > > Were you using a different board file that exercised gdbserver running on a remote host? Indeed specific boards for ARC are used. And yes, there were/are 2 ways that these boards were executed: through a simulator and on real boards (remote hosts). > > I'm trying to understand what the problem is. > >> >> gdb/testsuite/ChangeLog: >> 2016-12-16 Anton Kolesov <Anton.Kolesov@synopsys.com> >> >> * gdb.base/fileio.exp: Use "target" instead of "host". >> >> Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> >> --- >> gdb/testsuite/gdb.base/fileio.exp | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp >> index 9735869e5190..627a685e118d 100644 >> --- a/gdb/testsuite/gdb.base/fileio.exp >> +++ b/gdb/testsuite/gdb.base/fileio.exp >> @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] { >> standard_testfile >> -if {[is_remote host]} { >> +if {[is_remote target]} { >> set outdir . >> } else { >> set outdir [standard_output_file {}] >>
* Shahab Vahedi <shahab.vahedi@gmail.com> [2020-02-07 15:59:50 +0100]: > From: Anton Kolesov <Anton.Kolesov@synopsys.com> > > Fileio test improperly checks if [is_remote host] and if it is, then > uses file path that is safe to use on remote host. But the problem is > that [is_remote host] returns state of *this* host, not of the remote > target, where filepaths actually matter. This patch fixes that. > > gdb/testsuite/ChangeLog: > 2016-12-16 Anton Kolesov <Anton.Kolesov@synopsys.com> > > * gdb.base/fileio.exp: Use "target" instead of "host". > > Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> I don't really understand what the problem is here. I'm probably just not understanding things, so please, correct let me know where I'm going wrong, but I thought.. 'is_remote host' - when this is true we're running dejagnu on machine A, but actually running GDB on machine B. GDB might then be talking to a remote target on machine C, or maybe the test is also running on machine B. 'is_remote target' - when this is true the thing being debugged is not a child of the GDB process, it could be on a different machine, or it could be gdbserver on the same machine, but it still seems to be "remote" as far as GDB is concerned. The fileio.exp test is I think testing remote fileio, not native fileio, so when the test tries to open a file, it will be GDB that actually opens the file for us. So, if 'is_remote host' is false, then the files we open should be in the local dejagnu file system, with the longer paths, while if 'is_remote host' is true, then I think the assumption is that GDB will have been pushed over from the local tree to the remote host, and we don't have the full file system hierarchy, so lets just use '.' as a path prefix. I don't think this test really makes much sense when 'is_remote target' is false, otherwise we're just testing, what? That GDB doesn't prevent the target doing IO? And once upon a time we indeed made this check, see commit 1bcdb42447a4a68d7c3837b3852db3fb632e379b, but this was quickly changed in b257a0d30ab67df224f603c928127f2e653660b9 to a check based on the target properties. If I was going to guess, I'd guess your target can do real IO, into a local file system? I think, if this is the case you should be setting 'set_board_info gdb,nofileio 1' in your board file - but like I say, this is just a guess. Thanks, Andrew > --- > gdb/testsuite/gdb.base/fileio.exp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp > index 9735869e5190..627a685e118d 100644 > --- a/gdb/testsuite/gdb.base/fileio.exp > +++ b/gdb/testsuite/gdb.base/fileio.exp > @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] { > > standard_testfile > > -if {[is_remote host]} { > +if {[is_remote target]} { > set outdir . > } else { > set outdir [standard_output_file {}] > -- > 2.25.0 >
diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp index 9735869e5190..627a685e118d 100644 --- a/gdb/testsuite/gdb.base/fileio.exp +++ b/gdb/testsuite/gdb.base/fileio.exp @@ -23,7 +23,7 @@ if [target_info exists gdb,nofileio] { standard_testfile -if {[is_remote host]} { +if {[is_remote target]} { set outdir . } else { set outdir [standard_output_file {}]