SIGSEGV question (Hexagon)

SIGSEGV question (Hexagon)

[Taylor Simpson]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Philippe suggested that I run the TCG tests for Hexagon.  Thanks Philippe!!

I discovered that I'm not handling SIGSEGV properly.  We pass other signal tests, but not this one.  I'm hoping someone can help.  The first thing that I realized is that I hadn't provided a tlb_fill function for CPUClass.  What is this function supposed to do?  I looked at other targets and found they are setting cs->exception_index to something and then call cpu_loop_exit_restore.  I tried various values for exception_index, but the best I seem to get is re-executing the offending instruction forever.

Any insight would be greatly appreciated.

Thanks,
Taylor


PS  The only other bug that these tests uncovered was that truncate isn't implemented properly.  This was straightforward to fix.


[-- Attachment #2: Type: text/html, Size: 5251 bytes --]

Re: SIGSEGV question (Hexagon)

[Alex Bennée]

Taylor Simpson <tsimpson@quicinc.com> writes:

> Philippe suggested that I run the TCG tests for Hexagon.  Thanks Philippe!!
>
>
>
> I discovered that I’m not handling SIGSEGV properly.  We pass other signal tests, but not this one.  I’m hoping someone can help.
>  The first thing that I realized is that I hadn’t provided a tlb_fill function for CPUClass.  What is this function supposed to
> do?

It's does two subtly different things depending on system emulation vs
user-mode:

 * @tlb_fill: Callback for handling a softmmu tlb miss or user-only
 *       address fault.  For system mode, if the access is valid, call
 *       tlb_set_page and return true; if the access is invalid, and
 *       probe is true, return false; otherwise raise an exception and
 *       do not return.  For user-only mode, always raise an exception
 *       and do not return.

>I looked at other targets and found they are setting
>cs->exception_index to something and then call cpu_loop_exit_restore.

cpu_loop_exit_* brings you back to the sigsetjmp of cpu_exec short
circuiting any more TCG code. For linux-user the exception code should
get kicked back to cpu_loop. As we are jumping out of the TCG all your
CPUState should be coherent by this point. For pure TCG code this should
be the case. If you have faulted in a helper this could be problematic.

> I tried various values for exception_index, but the best I seem to get
> is re-executing the offending instruction forever.

For linux-user you need to then catch that exception in your cpu_loop
code and do the requisite setting up (probably a queue_signal in this
case). This should get picked up by the process_pending_signal at the
end of your cpu_loop which will then set the PC as appropriate to your
signal handler.

This is where we find out if your CPUState is now consistent ;-)

>
>
>
> Any insight would be greatly appreciated.
>
>
>
> Thanks,
>
> Taylor
>
>
>
>
>
> PS  The only other bug that these tests uncovered was that truncate isn’t implemented properly.  This was straightforward to fix.


--
Alex Bennée

RE: SIGSEGV question (Hexagon)

[Taylor Simpson]

Thanks a ton Alex!!

It's working for me now.

Taylor



-----Original Message-----
From: Qemu-devel <qemu-devel-bounces+tsimpson=quicinc.com@nongnu.org> On Behalf Of Alex Bennée
Sent: Tuesday, November 5, 2019 4:13 AM
To: qemu-devel@nongnu.org
Subject: Re: SIGSEGV question (Hexagon)

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Taylor Simpson <tsimpson@quicinc.com> writes:

> Philippe suggested that I run the TCG tests for Hexagon.  Thanks Philippe!!
>
>
>
> I discovered that I’m not handling SIGSEGV properly.  We pass other signal tests, but not this one.  I’m hoping someone can help.
>  The first thing that I realized is that I hadn’t provided a tlb_fill
> function for CPUClass.  What is this function supposed to do?

It's does two subtly different things depending on system emulation vs
user-mode:

 * @tlb_fill: Callback for handling a softmmu tlb miss or user-only
 *       address fault.  For system mode, if the access is valid, call
 *       tlb_set_page and return true; if the access is invalid, and
 *       probe is true, return false; otherwise raise an exception and
 *       do not return.  For user-only mode, always raise an exception
 *       and do not return.

>I looked at other targets and found they are setting
>cs->exception_index to something and then call cpu_loop_exit_restore.

cpu_loop_exit_* brings you back to the sigsetjmp of cpu_exec short circuiting any more TCG code. For linux-user the exception code should get kicked back to cpu_loop. As we are jumping out of the TCG all your CPUState should be coherent by this point. For pure TCG code this should be the case. If you have faulted in a helper this could be problematic.

> I tried various values for exception_index, but the best I seem to get
> is re-executing the offending instruction forever.

For linux-user you need to then catch that exception in your cpu_loop code and do the requisite setting up (probably a queue_signal in this case). This should get picked up by the process_pending_signal at the end of your cpu_loop which will then set the PC as appropriate to your signal handler.

This is where we find out if your CPUState is now consistent ;-)

>
>
>
> Any insight would be greatly appreciated.
>
>
>
> Thanks,
>
> Taylor
>
>
>
>
>
> PS  The only other bug that these tests uncovered was that truncate isn’t implemented properly.  This was straightforward to fix.


--
Alex Bennée