Re: ping: Re: PATCH : allow to set length of hw watchpoints (e.g. for Valgrind gdbserver)

["Philippe Waroquiers" <philippe dot waroquiers at skynet dot be>]

On Fri, 27 May 2011 11:24:31 +0800 Yao Qi  wrote

> If I understand you correctly, this commands are only useful in
> gdbserver+valgrind.  If gdb is running in normal remote target, using
> `set remote hardware-watchpoint-length-limit' will make GDB work
> incorrectly.

Interesting remark. Waiting for the legal papers to be signed, it made
me work a little bit more, and allowed me to find a bug in the current
gdbserver hw watchpoint handling on x86 :
   linux-x86-low.c:511: A problem internal to GDBserver has been detected.
  Assertion `DR_FIRSTADDR <= regnum && regnum < DR_LASTADDR' failed.
I am attaching a new version of the patch which fixes this problem
+ attaching the test program.

The patch is supposed to be useful also for 'non Valgrind' gdbserver.

I think the current behaviour is inconsistent (whatever the gdbserver)
and the patch is making it more consistent.

Currently: the user can configure the nr of remote hw watchpoints
(default unlimited). GDB tries to place the watchpoints, and if it
fails, the user can then decide what to do (e.g. delete some watchpoints,
switch to software watchpoints, etc).
For a too long watchpoint, GDB silently switches to software watchpoints, which is
I find surprising : it will then run (hundreds of times?) slower without warning.

With the patch, a too long watchpoint will be handled similarly to too many
watchpoints. The user can then decide what to do for too long watchpoints
e.g. switch to software watchpoints, disable or delete some watchpoints, ...

For what concerns the bug: the problem is that the code in i386-low.c
can partially place a watchpoint, but to the contrary of i386-nat.c,
such a partial watchpoint will not be rolled back by breakpoint.c
The patch fixes this (as this bug is much easier to trigger with long
breakpoints which are accepted by gdb, but have to be rolled back
by gdbserver). 
To reproduce the bug, compile the attached s.c, and do the following:
     gdbserver :1234 ./s
gdb ./s
tar rem :1234
set breakpoint always-inserted on
watch s1
watch s2
watch s4
watch s3
del
y
break s.c:24
c
p p = &s3
c
       linux-x86-low.c:511: A problem internal to GDBserver has been detected.
       Assertion `DR_FIRSTADDR <= regnum && regnum < DR_LASTADDR' failed.

If you enable remote hw points debugging, you will see that after having deleted all
watchpoints, some debug registers are still set.
The patch fixes this by adding a rollback.

Question: is there somewhere a 'how to test gdbserver for dummies' ?
I read the gdb internal doc, and could only find a reference to
setting GDBSERVER=... variable when doing make check, but that does
not run the gdbserver tests (I believe).
I took a look at dejagnu documentation, but that is not for a dummy like me :).
In the meantime, I have only done limited manual tests.

Philippe

Attachment: s.c
Description: Binary data

Attachment: set-lenght-limit-5.txt
Description: Text document