Re: [RFC 0/3] Use reinsert breakpoint for vCont;s

[Antoine Tremblay <antoine.tremblay@ericsson.com>]

Antoine Tremblay writes:

>> I tried different ways to remove reinsert breakpoints in GDBserver, but still
>> can't fix fails in gdb.threads/schedlock.exp, that the program gets SIGILL or
>> SIGSEGV.  These fails can't happen in every run, and they are disappeared
>> when I turn on debugging output in GDBserver.  I suspect they are about the
>> improper management to reinsert breakpoints.
>>
>
> I'm not sure at the moment but this makes me think of an issue I sent
> here: https://www.sourceware.org/ml/gdb/2015-11/msg00030.html
>
> Actually thanks to a good discussion with LTTng maintainer, (Mathieu
> Desnoyer) last week I got the hint that this could be due to the
> situation described here:
> https://community.arm.com/groups/processors/blog/2010/02/17/caches-and-self-modifying-code
>
> Short story, the instruction cache could be out of sync after we've
> removed a software breakpoint and the processor would execute the
> breakpoint instruction causing a SIGILL rather then the original memory.
>
> The solution however, calling __clear_cache(...) requires that we're in
> the same process for the memory addresses to be valid, I think, so I'm
> not sure how to fix this yet...
>
> I'm still early in my investigation but it may be something to consider.
>

Note I tracked that down to __flush_ptrace_access in the kernel, and
tried to hardcode the instruction cache flush (Thanks to Will Deacon for
the hints) but that did not help, at least on the odroid ux4.

Not an easy problem, I'm installing your patch series today and I'll
start checking it out in more detail.

Thanks,
Antoine