Re: False positive permanent breakpoints

> If you don't have software breakpoints in the list, then
> bp_location_has_shadow will return false for all breakpoints?
> Sounds like we could skip most of the work, but that's an
> optimization, not a correctness issue?
Yeah, I guess we can live with the minor performance impact we have for now
(and fix that in the future).

> I can't think of any offhand.  Mainly because it's not usual for me to
> work with targets that don't support sofware breakpoints.  So I'd
> say -- try it and see what breaks.  Which you already did.  :-)
Alright, thanks!

- Ofir Cohen

On 26 October 2016 at 18:13, Pedro Alves <[email protected]> wrote:
> On 10/26/2016 04:02 PM, Ofir Cohen wrote:
>>> I'd rather that upstreaming that bit was done when the
>>> rest of the port is submitted as well.
>> Alright, will do.
>>
>> As a temporary mitigation,
>> Is it OK for the target to return NULL from gdbarch_breakpoint_from_pc
>> to state that it doesn't support software breakpoints ?
>>
>
> I think so.
>
>>
>> There are some places that check that return value, like:
>> /* Software breakpoints unsupported?  */
>> if (bpoint == NULL)
>>   return 0;
>>
>> in bp_loc_is_permanent(), and others that don't, like breakpoint_xfer_memory().
>> Furthermore, it performs pointer arithmetic based on the returned value.
>
> If you don't have software breakpoints in the list, then
> bp_location_has_shadow will return false for all breakpoints?
> Sounds like we could skip most of the work, but that's an
> optimization, not a correctness issue?
>
>>
>> Currently the tests we have pass, but I'm concerned about other corner
>> cases are not covered
>> that might pop up as a result of this change.
>
> I can't think of any offhand.  Mainly because it's not usual for me to
> work with targets that don't support sofware breakpoints.  So I'd
> say -- try it and see what breaks.  Which you already did.  :-)
>
> Thanks,
> Pedro Alves
>