[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGSEGV question (Hexagon)
From: |
Alex Bennée |
Subject: |
Re: SIGSEGV question (Hexagon) |
Date: |
Tue, 05 Nov 2019 10:13:22 +0000 |
User-agent: |
mu4e 1.3.5; emacs 27.0.50 |
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