From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcbeP-0001ll-Ow for qemu-devel@nongnu.org; Fri, 10 Oct 2014 10:58:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XcbeJ-0002Rt-Kd for qemu-devel@nongnu.org; Fri, 10 Oct 2014 10:58:37 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:50881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XcbeJ-0002Rm-D8 for qemu-devel@nongnu.org; Fri, 10 Oct 2014 10:58:31 -0400 Message-ID: <5437F413.80100@huawei.com> Date: Fri, 10 Oct 2014 16:58:27 +0200 From: Claudio Fontana MIME-Version: 1.0 References: <1412914976-15800-1-git-send-email-amanieu@gmail.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] linux-user: Fix fault address truncation AArch64 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Amanieu d'Antras Cc: Riku Voipio , QEMU Developers On 10.10.2014 13:32, Peter Maydell wrote: > On 10 October 2014 05:22, Amanieu d'Antras wrote: >> On AArch64 the si_addr field of siginfo_t is truncated to 32 bits >> because the fault address passes through an uint32_t variable. This >> is fixed by changing the variable to uint64_t. >> >> Signed-off-by: Amanieu d'Antras >> --- >> linux-user/main.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/linux-user/main.c b/linux-user/main.c >> index 483eb3f..d63e093 100644 >> --- a/linux-user/main.c >> +++ b/linux-user/main.c >> @@ -1006,7 +1006,7 @@ void cpu_loop(CPUARMState *env) >> CPUState *cs = CPU(arm_env_get_cpu(env)); >> int trapnr, sig; >> target_siginfo_t info; >> - uint32_t addr; >> + uint64_t addr; >> >> for (;;) { >> cpu_exec_start(cs); > > Thanks for catching this. Better to fix it by dropping > the unnecessary local variable completely and just setting > info._sifields._sigfault._addr = env->exception.vaddress; > at the only point where we currently use 'addr', though, > I think. > > -- PMM We do use the name code pattern in most of the functions of that file, meaning uint32_t / uint64_t / target_ulong addr; and then do_something_with_addr(addr); Ciao, Claudio