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

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 13 December 2011 17:23:18, Jan Kratochvil wrote:
> On Mon, 12 Dec 2011 21:13:51 +0100, Pedro Alves wrote:
> > Maybe we should still have something like
> > 
> > if { istarget [ia64*-*-*] || .... } {
> >   set_board_info gdb,no_hardware_watchpoints 1
> > }
> > 
> > somewhere gdbserver specific.
> 
> The correct would be if gdbserver sends hardware watchpoints support in the
> qSupported reply and GDB can print the response in some way.

We've been avoiding that, as it turns into a rathole fast.
It's not really binary: you have multiple types of watchpoints,
and targets that can do arbitrarily wide watched areas, others
can only watch some ranges, etc.  It related to the desire to
even get rid of watchpoint resource accounting.

> 
> In reality proposing to add to
> 	http://sourceware.org/gdb/wiki/TestingGDB#Native_Board_File
> your proposed:
> 	# Some FSF gdbserver targets can't do hardware watchpoints.
> 	if [istarget "ia64*-*-*"] {
> 	  set_board_info gdb,no_hardware_watchpoints 1
> 	}

That'd obviously work, but that's not what I was proposing,
as I don't think this file is the ideal place.  I mean, if you
do a cross test run from x86-linux x ia64-linux gdbserver, you
won't use that board file.

Anyway, I was just pointing out the existence of other
platforms; this is hardly something to worry much about.

> > Some ports, like ia64 gdbserver
> > don't support watchpoints.  I think you can test a native
> > gdbserver with this board on ia64-linux, but this isn't really
> > native board specific --- a cross test should find watchpoints
> > support disabled too.  Maybe in gdbserver-support.exp?  WDYT?
> 
> I do not find gdbserver-support.exp appropriate as the problem of missing ia64
> watchpoints in FSF gdbserver does not apply to other implementations of
> gdbserver while gdbserver-support.exp still gets used for non-FSF gdbservers.

It does?  I wasn't aware of that.  The file is very GDBserver (our server)
specific.  It expects the command line to be compatible at least.  Do you
know of any such non-FSF project?

(I wish other projects wouldn't call their servers gdbservers)

> Unless there is qSupported I find the board file appropriate, as it describes
> the specific gdb<->gdbserver setup.
> 
> But I am far from experienced with advanced gdbserver stuff.
> 
> 
> > > +load_lib gdbserver-support.exp
> > > +
> > > +if {[skip_hw_watchpoint_access_tests]
> > > +    || (![istarget "i?86-*-linux*"] && ![istarget "x86_64-*-linux*"])
> > > +    || ([is_remote target] && [skip_gdbserver_tests])} {
> > > +    return 0
> > > +}
> > 
> > > +
> > > +if [is_remote target] {
> > > +    gdbserver_start_extended
> > > +}
> > 
> > Hmm, I'm not sure if this is really a good idea to spread
> > gdbserver_start_extended around like this.  I think it would be
> > better to skip the test if testing against plain "target remote".
> > I mean, you may be remote testing against qemu, for example.  Having
> > the test spawn GDBserver and actually run would be misleading.  Once
> > we have a board that tests the whole testsuite with extended-remote
> > working, then we'll clearly want the present board to skip tests
> > it doesn't support.  (the gdb.server/ tests being the exception.)
> > WDYT?
> 
> I have described this in:
> 	http://sourceware.org/ml/gdb-patches/2011-12/msg00088.html
> 
> Personally I would prefer always to follow the rules from there:
>    * Some testcases skip themselves if their mode/board is not satisfied.
>      --- if [is_remote target] then { return 0 }
>  * If a testcase is compatible with any mode/board it uses the mode/board
>    specified by user for the testsuite.
> 
> Therefore gdb.server/ would get whole skipped during the normal run.

The whole point of gdb.server/ is to exercise GDBserver (our server,
not someone else's) specific functionality, and make sure it isn't a
brick (a bit like gdb.gdb/).  E.g., server-mon.exp will almost certainly
fail on other servers.  Another special issue with these tests
is e.g., things like

  gdb_test_no_output "set remote exec-file $target_exec" "set remote exec-file"

hardcoded on the tests.  A board file that always spawned
gdbserver in extended-remote will certainly do "set remote exec-file "
somewhere within gdb_load, behind the test file's back.

That's why these gdb.server/ tests are special.

> Currently I run the testsuite already in multiple modes and some testcases run
> in duplicate configurations that way, costing needless time+power=money.

I'd be fine to restrict them to native runs (that's how Dan originally
designed them), and get back to this once we have better support for
testing everything in extended-remote mode.

> 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.

> But gdb.server/ext-*.exp do exactly the same so they have to be
> changed all together. 

I disagree, they don't have to.

-- 
Pedro Alves