[lldb-dev] Problem with watchpoints

Fri Sep 9 14:13:04 PDT 2016

I have also noticed a few problems similar to Ted's and I plan to
address them assuming nobody else is already on it.  That said, I am new
around here so please bear with me :)

In fact, I have been hacking on a few watchpoint methods for a while
now.  I have implemented some features I personally wanted (specifically
callback functions in the SBWatchpoint api). 

I have not yet created a PR (or whatever SVN equivalent) for several
reasons (obviously including the big reformat), but mostly I am a bit
lost with respect to proper procedure here.  I have gone through the
code guidelines for LLVM and LLDB, but I am confused about some things.

* I have written unit test logic, but I don't really understand the LLDB
testing framework.  Also, I understand from other threads that the
framework is currently in flux in any case.

* I have written documentation, but I don't know if what I have written
is even desirable.  For instance, the corresponding breakpoint
implementation is almost totally lacking in source doc.

* I will need to rebase this patch on the reformatted code.  That is no
big deal, but I have little experience with SVN and I will need to do
some research to avoid turning an eventual merge into a big chore.

* I am pretty unclear on the appropriate way to make my changes work
with the Python API.  Should that be on a different PR?  Are we
targeting Python 2.7 and 3.{4,5} on all platforms?

* Do I need to check that the test suite passes on other platforms, or
will other devs take care of that?  I don't use OSX or Windows.

Basically, I would like to help, but more than that I want my "help" to
be helpful.

If somebody who knows what is going on would help me out I would greatly
appreciate it.

\author{Daniel Noland}

On 09/09/2016 11:28 AM, Greg Clayton via lldb-dev wrote:
>> On Sep 8, 2016, at 4:47 PM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> I recently discovered a problem with watchpoints talking to the Hexagon simulator:
>>  
>> (lldb) w s e 0x1000
>> error: Watchpoint creation failed (addr=0x1000, size=4).
>> error: Target supports (0) hardware watchpoint slots.
>>  
>>  
>> It seems that lldb now sends a qWatchpointSupportInfo packet. But this packet isn’t defined in lldb-gdb-remote.txt.
>>  
>> Looking at the code, it expects to get back a pair “num:#”. If it doesn’t it returns 0. The caller will report the above error if the number returned is 0. So if qWatchpointSupportInfo isn’t supported, lldb can’t set a watchpoint.
>>  
>>  
>> What is the definition of the response to qWatchpointSupportInfo? Is the the number of supported watchpoints, or the number of available watchpoints? If it’s supported, then CheckIfWatchpointsExhausted won’t really check if the watchpoints are exhausted. If it’s available, then a return of 0 doesn’t let us aggregate watchpoints – a 4 byte watchpoint at 0x1000 and one at 0x1004 could be one going from 0x1000-0x1007.
> The person that checked this in no longer is working on LLDB and it has been like this since May 2012. It should return the total number of supported watchpoints. 
>>  
>> Wouldn’t it be better to try to set the watchpoint, then report a failure if we get an error back from the remote server?
> It is kind of nice to know that you can't set watchpoints because they aren't supported since we can provide a nicer message than "E98 returned from GDB server". Errors in GDB remote protocol are a horrible mess and they don't mean anything. So any clearer we can be about this, the better, so we should keep the qWatchpointSupportInfo packet IMHO. I am fine with us modifying the GDBRemoteCommunicationClient to try and send this packet and if it comes back as unimplemented (response of $#00), you can set the num supported hardware watchpoints to UINT32_MAX. We should document that this means we don't know how many hardware watchpoints are supported, but it should then allow us to set hardware watchpoints if the GDB server doesn't support this packet. 
>
> Watchpoints definitely need some work as they were done quickly by someone that is no longer around and they could use some TLC. 
>
>>  
>> --
>> Qualcomm Innovation Center, Inc.
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>>  
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160909/91104f0a/attachment.sig>