qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).