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
On 12 October 2015 at 13:41, Sergey Fedorov wrote:
> If I understand correctly, the last item in the list specifies that any
> page fault exception which would occur in the normal instruction
> execution has more priority than the breakpoint exception. If so,
> Everything
On 9 October 2015 at 14:53, Sergey Fedorov wrote:
> On 08.10.2015 21:40, Peter Maydell wrote:
>> On 28 September 2015 at 11:07, Sergey Fedorov wrote:
>>> A QEMU breakpoint match is not definitely an architectural breakpoint
>>> match. If an exception
On 08.10.2015 21:40, Peter Maydell wrote:
> On 28 September 2015 at 11:07, Sergey Fedorov wrote:
>> A QEMU breakpoint match is not definitely an architectural breakpoint
>> match. If an exception is generated unconditionally during translation,
>> it is hardly possible to
On 09.10.2015 17:00, Peter Maydell wrote:
> On 9 October 2015 at 14:53, Sergey Fedorov wrote:
>> On 08.10.2015 21:40, Peter Maydell wrote:
>>> On 28 September 2015 at 11:07, Sergey Fedorov wrote:
A QEMU breakpoint match is not definitely an
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
On 09.10.2015 17:04, Peter Maydell wrote:
> On 9 October 2015 at 14:59, Sergey Fedorov 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
On 9 October 2015 at 16:55, Sergey Fedorov wrote:
> 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)
On 9 October 2015 at 14:59, Sergey Fedorov 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
On 09.10.2015 17:04, Peter Maydell wrote:
> On 9 October 2015 at 14:59, Sergey Fedorov 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
On 28 September 2015 at 11:07, Sergey Fedorov wrote:
> A QEMU breakpoint match is not definitely an architectural breakpoint
> match. If an exception is generated unconditionally during translation,
> it is hardly possible to ignore it in the debug exception handler.
>
>
A QEMU breakpoint match is not definitely an architectural breakpoint
match. If an exception is generated unconditionally during translation,
it is hardly possible to ignore it in the debug exception handler.
Generate a call to a helper to check CPU breakpoints and raise an
exception only if any
12 matches
Mail list logo