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

[Joel Brobecker <brobecker at adacore dot com>]

> >>  - 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.  :-)

Sorry! This one:

    | but we'll need to create/clone the location and its shadow buffer,
    | and then still handle the issue in the "remove" path.

> 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.

OK - I will take care of that.

> 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.

I am wondering how to create that test, because it would be
a little tricky. We need to set ourselves into a situation
where we single-step out of a breakpoint with the second SSS
breakpoint being at the same address as one of the user breakpoints,
that second SSS not being the one that gets hit during that
first single-step-out-of-breakpoint.  The only way I can see
to achieve that, at the moment, is with a function call.
The only reliable way to do that, I think, is with an assembly
file, which means it'd be limited to a certain architecture.

> 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).

Ugh! Much trickier than I thought! :-(

So, to summarize, I'll start by working on a new patch, which I'll
send here. I'll also try to put the new testcase on the list, but
today is a little bit of a full day for me, so that part might have
to wait until Monday depending on how well my day goes.

Thanks, Pedro!
-- 
Joel