qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <rth@twiddle.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Emilio G. Cota" <cota@braap.org>
Subject: Re: [Qemu-devel] how do we determine correct guest PC for segfaults in atomic helpers for linux-user mode?
Date: Tue, 14 Nov 2017 12:23:18 +0000	[thread overview]
Message-ID: <87k1yt9hhl.fsf@linaro.org> (raw)
In-Reply-To: <b4c558f5-3b8e-52f0-4b66-c40519bc0500@twiddle.net>


Richard Henderson <rth@twiddle.net> writes:

> On 11/13/2017 08:59 PM, Peter Maydell wrote:
>> I've been investigating a bug (a javac crash). I'm not sure if it's
>> the root cause, but I can't figure out how, if we get a guest SEGV in
>> an atomic helper we report the right faulting PC to the guest.
>>
>> Specifically, if you get a SEGV here:
>>
>> #0  0x000000006003c22b in helper_atomic_cmpxchgl_le (env=0x63caf680,
>>     addr=275041819628, cmpv=0, newv=1)
>>     at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/atomic_template.h:65
>> #1  0x0000000061002f61 in static_code_gen_buffer ()
>> #2  0x0000000060035d6b in cpu_tb_exec (cpu=0x63ca73e0,
>>     itb=0x6119d000 <static_code_gen_buffer+9080960>)
>>     at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:167
>> #3  0x0000000060036945 in cpu_loop_exec_tb (cpu=0x63ca73e0,
>>     tb=0x6119d000 <static_code_gen_buffer+9080960>, last_tb=0x7f01b213dbd8,
>>     tb_exit=0x7f01b213dbd0)
>>     at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:611
>> #4  0x0000000060036bc2 in cpu_exec (cpu=0x63ca73e0)
>>     at /home/petmay01/linaro/qemu-from-laptop/qemu/accel/tcg/cpu-exec.c:723
>> #5  0x000000006003da13 in cpu_loop (env=0x63caf680)
>>     at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/main.c:809
>> #6  0x000000006004c627 in clone_func (arg=0x7ffe028f0a10)
>>     at /home/petmay01/linaro/qemu-from-laptop/qemu/linux-user/syscall.c:6241
>> #7  0x00000000602fcc25 in start_thread (arg=0x7f01b213e700)
>>     at pthread_create.c:333
>> #8  0x00000000603949a9 in clone ()
>>
>> then the code in handle_cpu_signal() is passed a pc of 0x6003c22b
>> (the location in the helper function that does the memory access).
>> This is outside generated code, so the call to cpu_restore_state()
>> in handle_cpu_signal() will do nothing. However as far as I can tell,
>> there isn't any syncing of the PC etc state to the CPU before calling
>> this helper (at least, env->pc is completely wrong for the insn that
>> I think is causing this helper call).
>>
>> Am I misreading my debugger entrails (entirely possible)? How is this
>> code intended to get the right guest PC for segfaults in these helpers?
>
> It looks like we can't.

I thought the GETPC() macro was a host specific way to find the return
address, hence the address in the TB that can be resolved?

>
> We get it right for system mode, but not linux-user.
>
> I suppose it would be fixable with a tls variable that is set by the helper,
> which could then be used by the signal handler in preference to the host pc
> indicated by the frame.  That seems kinda kludgy.
>
> Looking forward, we're going to need a way to catch these faults for the SVE
> FFR.  Perhaps a tls pointer to a jmp_buf can do both.  If the pointer is
> non-null, host_signal_handler does nothing for SIGSEGV, SIGBUS.  For SVE, we
> end the first-faulting load sequence.  For atomic linux-user, we call into a
> version of handle_cpu_signal with the proper code_gen_buffer return address.
>
> Thoughts?
>
> r~


--
Alex Bennée

      parent reply	other threads:[~2017-11-14 12:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 19:59 [Qemu-devel] how do we determine correct guest PC for segfaults in atomic helpers for linux-user mode? Peter Maydell
2017-11-13 22:53 ` Philippe Mathieu-Daudé
2017-11-13 23:31 ` Richard Henderson
2017-11-14  8:52   ` Peter Maydell
2017-11-14  9:06     ` Richard Henderson
2017-11-14 12:23   ` Alex Bennée [this message]

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=87k1yt9hhl.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=cota@braap.org \
    --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).