All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Subject: Re: SIGSEGV question (Hexagon)
Date: Tue, 05 Nov 2019 10:13:22 +0000	[thread overview]
Message-ID: <87a79ak4vx.fsf@linaro.org> (raw)
In-Reply-To: <BYAPR02MB4886C25E683DEAFB1B8121FCDE7F0@BYAPR02MB4886.namprd02.prod.outlook.com>


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


  reply	other threads:[~2019-11-05 10:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-04 22:59 SIGSEGV question (Hexagon) Taylor Simpson
2019-11-05 10:13 ` Alex Bennée [this message]
2019-11-05 19:30   ` Taylor Simpson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a79ak4vx.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.