From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Richard Henderson <rth@twiddle.net>, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, leon.alrae@imgtec.com
Subject: Re: [Qemu-devel] [PATCH] tcg: Merge GETPC and GETRA
Date: Wed, 03 Aug 2016 17:42:40 +1000 [thread overview]
Message-ID: <1470210160.12584.64.camel@kernel.crashing.org> (raw)
In-Reply-To: <1469493760-4205-1-git-send-email-rth@twiddle.net>
On Tue, 2016-07-26 at 06:12 +0530, Richard Henderson wrote:
> The return address argument to the softmmu template helpers was
> confused. In the legacy case, we wanted to indicate that there
> is no return address, and so passed in NULL. However, we then
> immediately subtracted GETPC_ADJ from NULL, resulting in a non-zero
> value, indicating the presence of an (invalid) return address.
>
> Push the GETPC_ADJ subtraction down to the only point it's required:
> immediately before use within cpu_restore_state, after all NULL
> pointer
> checks have been completed. This makes GETPC and GETRA identical.
>
> Remove GETRA as the lesser used macro, replacing all uses with GETPC.
>
> Signed-off-by: Richard Henderson <rth@twiddle.net>
> ---
This causes a problem with linux-user. We have cases where a store
instruction from the guest turns into *one* store instruction in
the host. The PC we get from the host segfault is exact, so the -2
in cpu_restore_state() takes us to the previous instruction.
We thus end up reporting the wrong instruction in the signal
I've tentatively fixed it with the hack below. It's not pretty
since we were trying to get rid of all those GETPC_ADJ sprinkled
all over but I don't see any obvious better way.
I'm not sure if there are other cases with softmmu for example, where
we do get an exact host PC and thus where the -2 might take us back too
far.
I don't see your patch upstream yet so feel free to fold my change into
yours.
@@ -103,13 +102,16 @@ static inline int handle_cpu_signal(uintptr_t pc, unsigned long address,
return 0; /* not an MMU fault */
}
if (ret == 0) {
return 1; /* the MMU fault was handled without causing real CPU fault */
}
- /* now we have a real cpu fault */
- cpu_restore_state(cpu, pc);
-
+ /* Now we have a real cpu fault. We must undo the adjustment
+ * done by cpu_restore_state() since we aren't pointing to the
+ * next instruction but to the faulting one and going back
+ * can make us report the wrong guest PC.
+ */
+ cpu_restore_state(cpu, pc + GETPC_ADJ);
sigprocmask(SIG_SETMASK, old_set, NULL);
cpu_loop_exit(cpu);
/* never comes here */
return 1;
next prev parent reply other threads:[~2016-08-03 7:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 0:42 [Qemu-devel] [PATCH] tcg: Merge GETPC and GETRA Richard Henderson
2016-07-26 1:36 ` Benjamin Herrenschmidt
2016-07-26 11:36 ` Leon Alrae
2016-07-26 12:24 ` [Qemu-devel] [PATCH] ppc: Fix fault PC reporting for lve*/stve* VMX instructions Benjamin Herrenschmidt
2016-07-26 12:28 ` [Qemu-devel] [PATCH] tcg: Merge GETPC and GETRA Benjamin Herrenschmidt
2016-08-03 7:42 ` Benjamin Herrenschmidt [this message]
2016-08-06 9:30 ` Richard Henderson
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=1470210160.12584.64.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=leon.alrae@imgtec.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).