Re: [RFA/7.8] user breakpoint not inserted if software-single-step at same location

[Pedro Alves <palves at redhat dot com>]

On 05/30/2014 01:22 PM, Joel Brobecker wrote:

>> And in the "remove" path:
>>
>>  - if there's still a non-sss breakpoint inserted at the
>>    same address, then don't actually remove the breakpoint
>>    off of the target, just wipe it from gdb's list.
> 
> It seems to me that we'd need to merge your initial recommendation
> into your summary above, right?

I admit I don't know what recommendation you're referring to.  :-)

 Otherwise, wouldn't we fail in
> the async example you provided? Actually, wouldn't it fail
> regardless? Even if we inserted the SSS breakpoint, when the user
> deletes his breakpoints, since the breakpoint chain doesn't know
> about the SSS breakpoint, wouldn't it remove our SSS breakpoint
> insn?

Ah, yes.  We'd need the mirror treatment in bkpt_remove_location.

> 
> I am wondering whether the simpler approach that you initially
> suggested, which is to just handle the issue in the "remove"
> path for 7.8 wouldn't be a little safer

For 7.8, I'm thinking it's really safer to avoid resending
duplicate Z0 packets to stubs that don't support conditional
breakpoint evaluation on the target end.  So I think we should
handle the "insert" path too.

BTW, did you try creating a test for the issue you discovered?
I don't think we have anything that triggers this already in
the tree, otherwise I think I'd have seen it with my
software-single-step-on-x86 branch.

> , while we also look
> at actually enhancing SSS breakpoints via the normal breakpoint
> chain. I am wondering what's going to be needed for that...

I have done that at least two or three times before, and I was
never that happy with the result.  This was before the patch
that led to this regression, and that one and the surrounding
patches were actually result of exactly wanting to modernize
software single-step.  :-)  The main issue is that SSS breakpoints
and all other breakpoints need to be inserted/removed at
different times, and that is surprisingly tricky to handle.
But I'm hoping/assuming the codebase is a little bit more
ready now for the next attempt.  My main motivation is to
be able to enable non-stop without forcing displaced-stepping
for all single-steps (even those that don't step over a bkpt).

-- 
Pedro Alves