From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Shahab Vahedi <Shahab.Vahedi@synopsys.com>,
Luis Machado <luis.machado@linaro.org>,
Shahab Vahedi <shahab.vahedi@gmail.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
Francois Bedard <Francois.Bedard@synopsys.com>
Subject: Re: [PATCH 05/14] gdb/testsuite: Skip a few gdb.base/skip.exp tests for remote targets
Date: Wed, 26 Feb 2020 20:52:00 -0000 [thread overview]
Message-ID: <20200226205200.GM3317@embecosm.com> (raw)
In-Reply-To: <CH2PR12MB41357F3AEE368B40A2469D74B1ED0@CH2PR12MB4135.namprd12.prod.outlook.com>
* Anton Kolesov <Anton.Kolesov@synopsys.com> [2020-02-25 08:39:16 +0000]:
> > >
> > > This is not what i see with a standard remote gdbserver-based test. For board
> > "native-gdbserver" i see all the tests passing just fine.
> > >
> > > GDB gets fired up and these first few checks get done without connecting to
> > gdbserver. Then GDB proceeds to connect to gdbserver.
> > >
> > > This, again, seems to indicate there is some custom board file in your setup
> > that is implementing testsuite primitives (that prepare_for_testing calls)
> > differently than what is present in GDB's testsuite.
> > >
> > > Am i missing something?
> >
> > Anton, could you share your experience with us?
> >
>
> I don't remember the details, but if I read that correctly, the fix assumes
> that checks are done after connecting to the target. Perhaps the behavior has
> changed since the patch has been authored? We do use custom board, but I
> don't think it modifies test procedures like prepare_for_testing. It does
> however implement board specific open, close, and reboot procs, and for one
> server we implement custom gdb_comm_leave proc to ensure that each test is run
> with a new GDB instance, because GDB-instance reuse was causing troubles in
> some cases:
> https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-releases/dejagnu/nsim-extra.exp#L121
I'd be interested to know where you're doing the connect to a remote
type logic that it's getting triggered from 'prepare_for_testing'. My
first instinct is to say that's being done in the wrong place, but
maybe there's a really good reason (TM), but I don't think we should
modify this test until we understand what the reasoning is here.
Thanks,
Andrew
next prev parent reply other threads:[~2020-02-26 20:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 15:01 [PATCH 00/14] Fixes for GDB Testsuites Shahab Vahedi
2020-02-07 15:01 ` [PATCH 08/14] gdb/testsuite: Fix bug in break-unload-file Shahab Vahedi
2020-02-07 15:01 ` [PATCH 13/14] gdb/testsuite: Skip killed-outside when nosignals Shahab Vahedi
2020-02-07 15:01 ` [PATCH 10/14] gdb/testsuite: Fix gdb.base/chng-syms.exp for remote target Shahab Vahedi
2020-02-07 15:01 ` [PATCH 09/14] gdb/testsuite: Fix break-always.exp for enabled do_reload_on_run Shahab Vahedi
2020-02-07 15:01 ` [PATCH 12/14] gdb/testsuite: Skip on of the interp.exp test for remote targets Shahab Vahedi
2020-02-07 15:01 ` [PATCH 03/14] gdb/testsuite: Add exit_is_reliable proc Shahab Vahedi
2020-02-11 7:35 ` Luis Machado
2020-02-26 19:45 ` Andrew Burgess
2020-02-07 15:01 ` [PATCH 11/14] gdb/testsuite: Fix dbx.exp for remote targets Shahab Vahedi
2020-02-11 8:27 ` Luis Machado
2020-02-07 15:01 ` [PATCH 06/14] gdb/testsuite: Fix gdb.mi exit function Shahab Vahedi
2020-02-07 15:01 ` [PATCH 14/14] gdb/testsuite: Skip some compile.exp tests when running with gdb-comm board Shahab Vahedi
2020-02-07 15:01 ` [PATCH 01/14] gdb/testsuite: Fix an invalid is_remote check in fileio test Shahab Vahedi
2020-02-11 7:29 ` Luis Machado
2020-02-18 7:31 ` Shahab Vahedi
2020-02-26 19:38 ` Andrew Burgess
2020-02-07 15:01 ` [PATCH 04/14] gdb/testsuite: Avoid fake failures when exit is unreliable Shahab Vahedi
2020-02-11 8:10 ` Luis Machado
2020-02-18 15:41 ` Shahab Vahedi
2020-02-25 7:47 ` Anton Kolesov
2020-02-26 20:42 ` Andrew Burgess
2020-02-07 15:01 ` [PATCH 02/14] gdb/testsuite: Skip fileio.exp for remote targets Shahab Vahedi
2020-02-11 7:32 ` Luis Machado
2020-02-26 19:40 ` Andrew Burgess
2020-02-07 15:01 ` [PATCH 05/14] gdb/testsuite: Skip a few gdb.base/skip.exp tests " Shahab Vahedi
2020-02-11 8:20 ` Luis Machado
2020-02-18 15:45 ` Shahab Vahedi
2020-02-25 8:39 ` Anton Kolesov
2020-02-26 20:52 ` Andrew Burgess [this message]
2020-02-07 15:01 ` [PATCH 07/14] gdb/testsuite: Fix invalid watchpoint test in mi suite Shahab Vahedi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200226205200.GM3317@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=Anton.Kolesov@synopsys.com \
--cc=Francois.Bedard@synopsys.com \
--cc=Shahab.Vahedi@synopsys.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@linaro.org \
--cc=shahab.vahedi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).