I uploaded:
https://reviews.llvm.org/D25875
Can you see if that fixes the failures you were seeing.
I'm not sure why that step over is happening in the StopInfoWatchpoint. We
usually try to hide that sort of platform difference down in the process
plugins and then let the upper layers see the
Yeah, sorry, that was an oversight on my part, but I think it's trivial to fix.
The WatchpointSentry was being set up before the little single step over the
watchpoint dance, and it was accidentally being used to get the watchpoint
disabled. That's not the main point of the sentry, which is to
Ok, after the latest round of changes, I was not able to reproduce the
behaviour where we would continually be-continually re-hitting a
watchpoint. However, I did manage to get the lldb-server to hang if I
set two watchpoints close to each other and trigger them both with a
single instruction. I ad
Ah, I see, thanks. If you can make a test case that fails on ARM in the
current state of things, I would be interested in taking a look at it. We had
to do an analogous little dance for stepping from one breakpoint to another.
Probably not the same solution, but we can surely get this to work
The reason you could not see this is that the issue is specific to arm
(or any target that reports watchpoint hits *before* executing the
instruction tripping the watch). In this case, we have special logic
in the client which removes the watchpoint, does a single step, and
reinstates the watchpoin
This revision was automatically updated to reflect the committed changes.
Closed by commit rL284706: Fix ARM/AArch64 Step-Over watchpoint issue remove
provision for duplicate… (authored by omjavaid).
Changed prior to commit:
https://reviews.llvm.org/D25057?vs=75103&id=75272#toc
Repository:
r
> On Oct 4, 2016, at 9:28 AM, Pavel Labath via lldb-commits
> wrote:
>
> Also, apparently lldb has a bug, where it mishandles the case where you do a
> (user-level) single step over an instruction triggering a watchpoint. That
> would be pretty important to fix as well.
Do you have a referen
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.
LGTM, thanks.
BTW, it looks like the linux kernel is about to grow support for proper
byte-range watchpoints
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461036.html.
omjavaid updated this revision to Diff 75103.
omjavaid added a comment.
Sorry I was on Holiday so couldnt get back to this earlier.
I ll get back to your comments about GDB packet sequence in a separate thread
after collecting further information.
I have made the suggested corrections in above
labath added a comment.
In https://reviews.llvm.org/D25057#560325, @omjavaid wrote:
> @labath Referring to your email on the mailing list.
>
> Thanks for helping out with this work.
>
> I think we should push this fix, as you suggested this does not fix
> everything in a holistic way but it corr
omjavaid added a comment.
@labath Referring to your email on the mailing list.
Thanks for helping out with this work.
I think we should push this fix, as you suggested this does not fix everything
in a holistic way but it corrects the functionality that is currently available
right now with li
[phabricator seems to be down, so I'll reply here]
Thank you for looking into this.
Hmm... I think we can consider this an improvement over the status quo, but
it's not going to solve the problem in all cases. E.g., on aarch64, a
single stp instruction with neon registers can access a block of me
omjavaid created this revision.
omjavaid added a reviewer: labath.
omjavaid added a subscriber: lldb-commits.
Herald added subscribers: samparker, srhines, danalbert, tberghammer, rengolin,
aemerson.
On ARM Linux targets watchpoints are reported by PTrace before the instruction
causing watchpoi
13 matches
Mail list logo
