[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    ping: Re: PATCH : allow to set length of hw watchpoints (e.g. for Valgrind gdbserver)
From:       philippe.waroquiers () skynet ! be (Philippe Waroquiers)
Date:       2011-05-31 18:06:00
Message-ID: 1A6A06B5CD4346FEB0EAE0998527F07D () soleil
[Download RAW message or body]


> If that was the only problem, than it'd be okay --- the user just
> shouldn't use the command then.  GDB will just do what the
> user told it to.  But, it looks like the patch changes the
> behavior _even_ if the user doesn't use the command.

Effectively, the patch changes the behaviour (but I believe in a more
consistent way). But if that is considered as not good, I can change
the patch so as to keep by default the old behaviour.

Note that thanks to the pointer Joel gave me for the gdbserver testing,
I have run the regression test suite (on debian 5.0 amd64) with and
without the patch, and there is no regression.

Now that I understand better how to test gdbserver, I will try to 
add a test which reproduces the gdbserver crash.

> 
>> The ideal solution, IMO, is remote side gives GDB the value of
>> hardware-watchpoint-length-limit, however, I don't know it is easy or
>> hard to do such thing.
> 
> We've also discussed completely getting rid of watchpoint
> resources accounting recently.
For sure, if that would appear, that would be nice.

I guess that what we need is a packet such as:
"here is a list of hw watchpoint, is this list ok ?" packet.

Note that one other thing that I find confusing in the current behaviour
is that if you have a certain set of hw watchpoints that were accepted
and you add a new one, you might obtain an error back referencing
an "old" accepted watchpoint.

I think it would be better if the watchpoints would always be re-inserted
by gdb in the same order.

Philippe


[prev in list] [next in list] [prev in thread] [next in thread]