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

[Joel Brobecker <brobecker@adacore.com>]

Hi Pedro,

Thanks for the super quick review!

> Async/background execution breaks that assumption though.

Hmmm, you are right. I had a feeling that this assumption was
going to come back to bite us one day. I didn't realize that
it was going to be today! ;-)

> We can still bypass actually inserting the sss breakpoint in
> the "insert" path if there's already another breakpoint there,
> but we'll need to create/clone the location and its shadow buffer,
> and then still handle the issue in the "remove" path.
[...]
> In sum, in the "insert" path:
> 
>  - if !target_supports_evaluation_of_breakpoint_conditions; then
>      optimize out the sss breakpoint if there's already a
>      non-sss breakpoint inserted at the same address.
>    else
>      make sure to resend/reinsert the breakpoint sss breakpoint,
>      even if there's already a non-sss in place, in case that other
>      breakpoint was conditional.
>    fi
> 
> 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? 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?

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

WDYT?

Thanks!
-- 
Joel