Re: [Qemu-devel] [PATCH v2 2/2] target-arm: Fix CPU breakpoint handling

[Sergey Fedorov <serge.fdrv@gmail.com>]

On 09.10.2015 17:04, Peter Maydell wrote:
> On 9 October 2015 at 14:59, Sergey Fedorov <serge.fdrv@gmail.com> wrote:
>> On 08.10.2015 21:40, Peter Maydell wrote:
>>> Annoying corner case which I don't think we need to handle necessarily:
>>> if you set a breakpoint on a 32-bit Thumb instruction which spans a page
>>> boundary, and the second page is not present, we will end up taking the
>>> page fault when I think we should take the breakpoint. I can't think
>>> of a way to get that right, so just commenting that it isn't handled
>>> right would do.
>> Could you please point out the piece of code which will generate the
>> page fault? Maybe I will give it a thought :)
> When you call arm_ldl_code() and friends, they will end up longjmp()ing
> out of the codegen phase if the load faults. This then turns into a
> guest-visible fault in the usual way.
>
> To avoid this you'd need to instead call functions which return
> a transaction status, but then:
>  (a) you need to restructure the translate.c code so it can
>  deal with the idea of backing out if the instruction isn't
>  actually present
>  (b) this still wouldn't work for linux-user mode, where we
>  don't have any way to say "do a memory access, but let me know
>  if it would fail rather than longjmping"

Thank you for the explanation, Peter. I see, if we do insn translation
then we take the page fault instead of the CPU breakpoint. As of user
mode, can we actually set any CPU breakpoint? If not, as I guess, then
(b) is not applicable to the possible solution that you have described.

Best regards,
Sergey