Thanks a ton Alex!! It's working for me now.
Taylor -----Original Message----- From: Qemu-devel <qemu-devel-bounces+tsimpson=quicinc....@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 <tsimp...@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
