Re: [PATCH] PR threads/10729: x86 hw watchpoints and non-stop mode

Pedro Alves
2011-12-16T15:17:20Z

Hi Jan,

sorry for the delay.

On Tuesday 13 December 2011 19:18:58, Jan Kratochvil wrote:
> On Tue, 13 Dec 2011 19:01:20 +0100, Pedro Alves wrote:
> > and get back to this once we have better support for
> > testing everything in extended-remote mode.
>
> We will still need to test GDB in legacy mode for compatibility reasons with
> non-FSF gdbservers and existing user setups of gdbserver. I do not see what
> will change with adding the new extended-remote mode to the existing set of
> modes required to be run.

Currently, because there's no extended-remote board, the only way to
be a bit certain that we aren't making extended-remote "attach"/"run"
support in gdbserver a brick is the gdb.server/ tests. Let's take a
look at what we're talking about:

$ ls gdb.server/*.exp
gdb.server/ext-attach.exp
gdb.server/ext-run.exp
gdb.server/file-transfer.exp
gdb.server/server-mon.exp
gdb.server/server-run.exp

That's it. Once we have a board that tests the whole testsuite in
extended-remote mote, the ext-*.exp tests become useless and
redundant, and so all uses of gdbserver_start_extended can be eliminated
-- we have plenty of regular tests that "run" and "attach". Meanwhile,
we don't such a board, so we live with the exception that the
tests force gdbserver, and extended-remote. This is what I mean
by revisiting later. (I don't see a point in adding a board variable
for "supports extended-remote" at this point.)

The other tests don't directly relate to the gdbserver_start_extended
discussion, but let's have a look for completeness. The file-transfer.exp
test could be adjusted to not require gdbserver, but instead detect the
remote or extended-remote target is being used, and skipped if
not. E.g., "remote put" fails with "command can only be used with
remote target" if used on any other target. With that adjustment,
the test could be moved elsewhere.

The gdb.server/server-mon.exp test exercise gdbserver (vs
any other 3rd-party server) specific bits. We could perhaps
adjust it to try "monitor help" or "monitor version"
(the latter doesn't work today, but it'd be reasonable
to add), and skipping the test if something not gdbserver
comes out. Such a change assumes PASS->UNSUPPORTED or
PASSes simply disappearing kind of regressions are
detected, but they should anyway.

The server-run.exp test is practically useless
everywhere. It's a tiny bit useful
on [istarget *-*-linux*], and the bit it tests
can only work as expected on use_gdb_stub boards. So we
could move it to say, gdb.base/, and adjust it to not
require gdbserver, and skip it if !use_gdb_stub.

> > > As a less ambitious change if you do not like gdbserver_start_extended in this
> > > testcase we can change it.
> >
> > That'd be my preference.
>
> AFAIK there currently does not exist any extended-mode board file so there
> does not make sense to check in a testcase requiring it.

The test works with the native target. It would be skipped for use_gdb_stub
boards, like many tests are. It looks worth it to check in to me.
What I disagree is spreading gdbserver_start_extended uses outside
of gdb.server/.

Jan, largely, we agree. Really.

> > > But gdb.server/ext-*.exp do exactly the same so they have to be
> > > changed all together.
> >
> > I disagree, they don't have to.
>
> With http://sourceware.org/gdb/wiki/TestingGDB#Native_Board_File they both run
> the server in extended mode.
>
> There is a difference in default mode gdb.server/ext-*.exp also run it in
> extended mode while this testcases runs in linux-nat mode in such case.

I was disagreeing in your claim that they have to be changed
all together... We can just simply put your test case in, without
the gdbserver_start_extended bit, skipped on use_gdb_stub, and leave
the gdb.server/ tests alone for a separate patch/change/discussion/whatever.
They _don't_ have to be changed all together, is what I'm saying.
Maybe I misunderstood you.

> Our opinion probably differs in that I find running GDB testing only in the
> default mode as insufficient.

Of course we agree here. You were the one complaining that the tests
run in all modes...

--
Pedro Alves