This is an archive of the discontinued LLVM Phabricator instance.

Fix r284795 for the !wp_triggers_after case
ClosedPublic

Authored by jingham on Oct 21 2016, 11:37 AM.

Details

Reviewers
labath
Summary

The single-step dance needed in the wp_triggers_after case was using the WatchpointSentry to disable the watchpoint, and enable it again after. That wasn't right, this should be an operation that happens unknown to the machinery that handles the watchpoint actions. So I changed it to by-hand disable/enable in the case where the step is needed, and then go on to set up the sentry.

Pavel, can you see if this works for you?

Diff Detail

Repository
rL LLVM

Event Timeline

jingham updated this revision to Diff 75455.Oct 21 2016, 11:37 AM
jingham retitled this revision from to Fix r284795 for the !wp_triggers_after case.
jingham updated this object.
jingham added a reviewer: labath.
jingham set the repository for this revision to rL LLVM.

Actually, that should be the !wp_triggers_after case...

jingham updated this revision to Diff 75461.Oct 21 2016, 12:29 PM

Tiny cleanup. I moved wp_triggers_after out of the process_sp check 'cause I though I might need to know it once the step was over, but then I didn't. So I moved it back.

labath requested changes to this revision.Oct 24 2016, 3:26 AM
labath edited edge metadata.

Unfortunately, this does not seem to do the trick, Upon hitting the watchpoint lldb enters a loop, where it continually tries to single-step, but never actually disables the watchpoint.

source/Target/StopInfo.cpp
696

This does not seem to cause the watchpoint to be disabled. It just ends up calling StoppointLocation::SetHardwareIndex(INVALID_INDEX), but no packet is sent that actually disables the watchpoint server-side.

This revision now requires changes to proceed.Oct 24 2016, 3:26 AM
jingham updated this revision to Diff 75666.Oct 24 2016, 7:08 PM
jingham edited edge metadata.

I swapped back into my brain how to run the testsuite on an arm64 iOS device. I verified (by the advanced means of putting a printf there) that we were doing the !wp_triggers_after single-step over watchpoint two-step in StopInfoWatchpoint::PerformAction.

Then I tried this patch using both wp_sp->SetEnabled({true, false}, false), and process_sp->{Enable,Disable}Watchpoint(wp_sp.get(), false) in the single-step over bit. In both cases it failed one testcase: TestStepOverWatchpoint.TestStepOverWatchpoint - which is an instruction single step over watchpoint failure. But all the other watchpoint tests passed, and I saw my printf a whole bunch of times, so that little dance was done successfully many times. And the one failing test didn't go into an infinite loop, it just got the wrong stop reason.

Maybe the Watchpoint::SetEnabled failure is something on your end? Anyway, I uploaded a new version of the patch that uses the Process method - which apparently does work for you or this never would have worked at all... Can you see if that works any better? If it does, then I'll check in this version, and we can file a PR about the Watchpoint::SetEnabled failure.

labath accepted this revision.Oct 25 2016, 5:38 AM
labath edited edge metadata.

It works now. Thanks for fixing it.

I am not sure how the previous version could have worked for you. If you look at ProcessGDBRemote::DisableWatchpoint, you see that it calls wp->SetEnabled(false) after it sends the "z" packet. It would be strange if SetEnabled() ended up calling back into DisableWatchpoint() (and I don't see any indications of that in the code).

source/Target/StopInfo.cpp
598

this variable seems to be unused.

This revision is now accepted and ready to land.Oct 25 2016, 5:38 AM
jingham closed this revision.Oct 25 2016, 1:44 PM

Thanks, Pavel.

Closed by 285114.