Page MenuHomePhabricator

Improve watchpoint error reporting specially for arm/aarch64 targets

Authored by omjavaid on Jun 8 2016, 6:20 PM.



This patch takes a few corrective measures to make sure we display meaningful reason against a watchpoint creation failure.

This is particularly important for the targets where we get to know dynamically about the availability of hardware watchpoint resources.

We are trying to check whether we have sufficient hardware watchpoint slots available before we go ahead and create a new watchpoint.

Diff Detail

Event Timeline

omjavaid updated this revision to Diff 60127.Jun 8 2016, 6:20 PM
omjavaid retitled this revision from to Improve watchpoint error reporting specially for arm/aarch64 targets.
omjavaid updated this object.
omjavaid added reviewers: tberghammer, labath.
omjavaid added a subscriber: lldb-commits.

Native register context changes seem legit. Adding Greg for the Target.cpp changes.

Any comments about this change? Thanks!

clayborg accepted this revision.Jun 20 2016, 3:30 PM
clayborg edited edge metadata.

Seems like CheckIfWatchpointsExhausted() inside Target.cpp works for some targets, but not all of them. Seems like this functionality should be pushed down into RegisterContext to do this right. For now this is OK, but we should file a bug to track fixing this correctly so that multiple watchpoints can share a single hardware watchpoint when possible.


This logic isn't necessarily correct. If we have the ability to watch N bytes at a time with a single hardware watchpoint, we might have 1 hardware watchpoint that is able to watch multiple things. So for code like:

char buffer[8] = ...;

then we watch "buffer[1]" and "buffer[7]", we could actually have 2 watchpoints but only use 1 hardware watchpoint. We really should be allowing each process plug-in to try and set the watchpoint and return the correct error instead of generically trying to catch _anything_ at the target level. So it seems like this code should be removed and moved into RegisterContext and allow each register context plug-in to respond correctly as only the it will know what can be done.

This revision is now accepted and ready to land.Jun 20 2016, 3:30 PM
omjavaid added inline comments.Jun 27 2016, 5:33 AM

I am seeing this a little different. GetWatchpointSupportInfo has to provide information on number of watchpoint resources a target supports.
We should only fail a watchpoint on the basis of GetWatchpointSupportInfo if it returns zero that is for a particular hardware we have no watchpoint support.

For the case where we want to utilize same hardware resource to watch multiple watchpoints, we should try to manage that in register context where we can keep track of watchpoints previously installed without getting the target backend involved. First we can attempt to intall a watchpoint using an existing resource and if that fails we can use a new hardware resource. Return failure if watchpoint resources are used up. This way you can put multiple watchpoint on same address without having to use up hardware watchpoint resources. I will post this solution of arm and aarch64 soon.


I am going to remove this case from final commit as we may have more watchpoints utilizing one or more hardware watchpoint resources.

This revision was automatically updated to reflect the committed changes.