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=address@hidden> On Behalf Of Alex 
Bennée
Sent: Tuesday, November 5, 2019 4:13 AM
To: address@hidden
Subject: Re: SIGSEGV question (Hexagon)

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

Taylor Simpson <address@hidden> 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