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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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.

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
	}


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

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.
Currently I run the testsuite already in multiple modes and some testcases run
in duplicate configurations that way, costing needless time+power=money.


As a less ambitious change if you do not like gdbserver_start_extended in this
testcase we can change it.  But gdb.server/ext-*.exp do exactly the same so
they have to be changed all together. we can introduce new:
	set_board_info gdb,extended_protocol_supported 1



Thanks,
Jan