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 should be okay.
Oh, good
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 shoul
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 is generated unconditionally during translatio
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 page is not present, we w
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 which spans a page
>>> bo
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) is not applicable to the
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 which spans a page
>>> bo
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 shoul
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 architectural breakpoint
match. If an exceptio
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 ignore it in the debug ex
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.
>
> Generate a call to a helpe
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 b
12 matches
Mail list logo
