From patchwork Tue Nov 10 08:30:32 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Vivier X-Patchwork-Id: 1397422 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=vivier.eu Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CVh1F0VMtz9sRK for ; Tue, 10 Nov 2020 19:32:01 +1100 (AEDT) Received: from localhost ([::1]:39926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcP4J-0000nH-0M for incoming@patchwork.ozlabs.org; Tue, 10 Nov 2020 03:31:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcP3A-0000lu-Bo for qemu-devel@nongnu.org; Tue, 10 Nov 2020 03:30:48 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:60635) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcP33-00072P-Lg for qemu-devel@nongnu.org; Tue, 10 Nov 2020 03:30:47 -0500 Received: from localhost.localdomain ([82.252.154.198]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MplPf-1jy9fn0hjh-00q7g7; Tue, 10 Nov 2020 09:30:38 +0100 From: Laurent Vivier To: qemu-devel@nongnu.org Subject: [PULL 1/3] linux-user/sparc: Fix errors in target_ucontext structures Date: Tue, 10 Nov 2020 09:30:32 +0100 Message-Id: <20201110083034.224832-2-laurent@vivier.eu> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201110083034.224832-1-laurent@vivier.eu> References: <20201110083034.224832-1-laurent@vivier.eu> MIME-Version: 1.0 X-Provags-ID: V03:K1:9oFgvkDpRNm4PETcAFgPop46tS7RCuM9Y/k184dnD7KJWoost+6 5kJJ6Wk1eSBH92h2Ag/jDbfmh6qBwRls2w9WXhIYSLBvoJy/PBTHwZyQrpP6gX1D/dTwOvX KTEJd7L4EKHsdT+4OHeyECPty8dHTdqDEqr9PPloXDMZT85xlPUhBSGKwFFmxnrLqgKHbeO /AOGEmpMEdRtJyZehPP/g== X-UI-Out-Filterresults: notjunk:1;V03:K0:BxLXC0GnuQ4=:gvWezoI7K93AO3gcla9Bgi HRmgI+APnAqGdGj8yPfntH4Savr5xij1pFl3DfOgdDwkRYjkEFi55SNMiiVobwLRyqXcY4UHh wjQ+cEVlReWvRd+FGpmpKHhBBHnbT0Xahl22XHnLTTuWGDSg55qK42WppDUoJEJtsrCkfTzHs rMZmMftL8KcOQRLnnyFOaz1tj3R+5TMNtWPjkEmRuEW9zmspUbSn5RMP8cf0XAf3GK29vg3H9 nUGNDJTUcTh2ulgEUnAqD4EH11BEkfzpJdUpmdq/VKxoKDyjTNBW0B6e6ANwOt9TEKGzIlcfB X5F5qy15w/wlCACCx2/R0KYf/Z6Cipxknmj0lXFFMlGySSi8LMD5Y/EdG9IvoY10qy4ytVBEO 2Vylgmxic3K4FVL4rNTS7+BZadljlrf28b9mSQ86YjzRRVvJfvXQeWxzFTOAs3Wig7O05d8dJ 3KxalpiIzg== Received-SPF: none client-ip=217.72.192.75; envelope-from=laurent@vivier.eu; helo=mout.kundenserver.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 03:30:39 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Richard Henderson , Laurent Vivier Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Peter Maydell The various structs that make up the SPARC target_ucontext had some errors: * target structures must not include fields which are host pointers, which might be the wrong size. These should be abi_ulong instead * because we don't have the 'long double' part of the mcfpu_fregs union in our version of the target_mc_fpu struct, we need to manually force it to be 16-aligned In particular, the lack of 16-alignment caused sparc64_get_context() and sparc64_set_context() to read and write all the registers at the wrong offset, which triggered a guest glibc stack check in siglongjmp: *** longjmp causes uninitialized stack frame ***: terminated when trying to run bash. Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Message-Id: <20201105212314.9628-2-peter.maydell@linaro.org> Signed-off-by: Laurent Vivier --- linux-user/sparc/signal.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c index d796f50f665b..57ea1593bfc9 100644 --- a/linux-user/sparc/signal.c +++ b/linux-user/sparc/signal.c @@ -349,10 +349,15 @@ typedef abi_ulong target_mc_greg_t; typedef target_mc_greg_t target_mc_gregset_t[SPARC_MC_NGREG]; struct target_mc_fq { - abi_ulong *mcfq_addr; + abi_ulong mcfq_addr; uint32_t mcfq_insn; }; +/* + * Note the manual 16-alignment; the kernel gets this because it + * includes a "long double qregs[16]" in the mcpu_fregs union, + * which we can't do. + */ struct target_mc_fpu { union { uint32_t sregs[32]; @@ -362,11 +367,11 @@ struct target_mc_fpu { abi_ulong mcfpu_fsr; abi_ulong mcfpu_fprs; abi_ulong mcfpu_gsr; - struct target_mc_fq *mcfpu_fq; + abi_ulong mcfpu_fq; unsigned char mcfpu_qcnt; unsigned char mcfpu_qentsz; unsigned char mcfpu_enab; -}; +} __attribute__((aligned(16))); typedef struct target_mc_fpu target_mc_fpu_t; typedef struct { @@ -377,7 +382,7 @@ typedef struct { } target_mcontext_t; struct target_ucontext { - struct target_ucontext *tuc_link; + abi_ulong tuc_link; abi_ulong tuc_flags; target_sigset_t tuc_sigmask; target_mcontext_t tuc_mcontext; From patchwork Tue Nov 10 08:30:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Vivier X-Patchwork-Id: 1397424 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=vivier.eu Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CVh3H2Rtwz9sPB for ; Tue, 10 Nov 2020 19:33:47 +1100 (AEDT) Received: from localhost ([::1]:46168 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcP61-0003W8-A5 for incoming@patchwork.ozlabs.org; Tue, 10 Nov 2020 03:33:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcP3A-0000mC-FW for qemu-devel@nongnu.org; Tue, 10 Nov 2020 03:30:48 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:37919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcP33-00072Q-6s for qemu-devel@nongnu.org; Tue, 10 Nov 2020 03:30:48 -0500 Received: from localhost.localdomain ([82.252.154.198]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1Mbj3Y-1k1g3631F0-00dFdc; Tue, 10 Nov 2020 09:30:38 +0100 From: Laurent Vivier To: qemu-devel@nongnu.org Subject: [PULL 2/3] linux-user/sparc: Correct set/get_context handling of fp and i7 Date: Tue, 10 Nov 2020 09:30:33 +0100 Message-Id: <20201110083034.224832-3-laurent@vivier.eu> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201110083034.224832-1-laurent@vivier.eu> References: <20201110083034.224832-1-laurent@vivier.eu> MIME-Version: 1.0 X-Provags-ID: V03:K1:JT4T9Y9GyDE9lgicWo6FjtB3XP+nELWswQm92onsqMjWca3RAyt axD+2A7oIi37Q7ElkM7xlmSm8ngkFrp7cRT0WmyjJneGKEde9NyETMt17owTBBvWrx52+2Z fl3D3/qnz3FV3cUy+8iA58I2K6W1bgq5Y2lviqAIoeV59FpAc9Wjz3OrCe261u2fhe5oiGz RjQdom2r3E4LIfN5v7jAg== X-UI-Out-Filterresults: notjunk:1;V03:K0:CMJsjlvygo4=:fElf4UZpvrzDFFaEzvU/ls 2+IlAXp4QiPbIJJg+kjRoKC5DHkmaFRNyj5rNrGLpsZhdOxtr1gvB9grC9Hk3+BtkOvDKUAMs l8unWyYRjBOyDJb8p0jC3ZZ7s6KAiDrTH35ucF2nv5uxnnsW8JVRfp9tDziOQnK+og4d8bSan gWfMbmYjhJv60V2qf/dDulmX/cRd995NId1c/o1O7c9YS3IXvvfBNbljbtt7CghrlLGV5Oo+Z lSad6G7fwytLiUWW2LTvxkKfNdletuLfS+yYV3gJLmDQf/JSykL2ey59zN4sZDARuKSXEM8b0 FDGCK0hYBudeaKWFexSGAIdGPanvJBCtyaKYEBXdoLR4WjWdIjL4aPkZutpgs+VGOcGI7nlM4 f6QxDwD4jUI2x5ScGpusw1b8oOraGPTkDUtDyIH6Hhw7hwDOdB9LA/aD4a80CbSLIx5Hc60TQ gEgu7gLkdw== Received-SPF: none client-ip=212.227.17.10; envelope-from=laurent@vivier.eu; helo=mout.kundenserver.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 03:30:38 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Richard Henderson , Laurent Vivier Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Peter Maydell Because QEMU's user-mode emulation just directly accesses guest CPU state, for SPARC the guest register window state is not the same in the sparc64_get_context() and sparc64_set_context() functions as it is for the real kernel's versions of those functions. Specifically, for the kernel it has saved the user space state such that the O* registers go into a pt_regs struct as UREG_I*, and the I* registers have been spilled onto the userspace stack. For QEMU, we haven't done that, so the guest's O* registers are still in WREG_O* and the I* registers in WREG_I*. The code was already accessing the O* registers correctly for QEMU, but had copied the kernel code for accessing the I* registers off the userspace stack. Replace this with direct accesses to fp and i7 in the CPU state, and add a comment explaining why we differ from the kernel code here. This fix is sufficient to get bash to a shell prompt. Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Message-Id: <20201105212314.9628-3-peter.maydell@linaro.org> Signed-off-by: Laurent Vivier --- linux-user/sparc/signal.c | 47 ++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 25 deletions(-) diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c index 57ea1593bfc9..c315704b3895 100644 --- a/linux-user/sparc/signal.c +++ b/linux-user/sparc/signal.c @@ -403,7 +403,6 @@ void sparc64_set_context(CPUSPARCState *env) struct target_ucontext *ucp; target_mc_gregset_t *grp; abi_ulong pc, npc, tstate; - abi_ulong fp, i7, w_addr; unsigned int i; ucp_addr = env->regwptr[WREG_O0]; @@ -447,6 +446,15 @@ void sparc64_set_context(CPUSPARCState *env) __get_user(env->gregs[5], (&(*grp)[SPARC_MC_G5])); __get_user(env->gregs[6], (&(*grp)[SPARC_MC_G6])); __get_user(env->gregs[7], (&(*grp)[SPARC_MC_G7])); + + /* + * Note that unlike the kernel, we didn't need to mess with the + * guest register window state to save it into a pt_regs to run + * the kernel. So for us the guest's O regs are still in WREG_O* + * (unlike the kernel which has put them in UREG_I* in a pt_regs) + * and the fp and i7 are still in WREG_I6 and WREG_I7 and don't + * need to be written back to userspace memory. + */ __get_user(env->regwptr[WREG_O0], (&(*grp)[SPARC_MC_O0])); __get_user(env->regwptr[WREG_O1], (&(*grp)[SPARC_MC_O1])); __get_user(env->regwptr[WREG_O2], (&(*grp)[SPARC_MC_O2])); @@ -456,18 +464,9 @@ void sparc64_set_context(CPUSPARCState *env) __get_user(env->regwptr[WREG_O6], (&(*grp)[SPARC_MC_O6])); __get_user(env->regwptr[WREG_O7], (&(*grp)[SPARC_MC_O7])); - __get_user(fp, &(ucp->tuc_mcontext.mc_fp)); - __get_user(i7, &(ucp->tuc_mcontext.mc_i7)); + __get_user(env->regwptr[WREG_FP], &(ucp->tuc_mcontext.mc_fp)); + __get_user(env->regwptr[WREG_I7], &(ucp->tuc_mcontext.mc_i7)); - w_addr = TARGET_STACK_BIAS + env->regwptr[WREG_O6]; - if (put_user(fp, w_addr + offsetof(struct target_reg_window, ins[6]), - abi_ulong) != 0) { - goto do_sigsegv; - } - if (put_user(i7, w_addr + offsetof(struct target_reg_window, ins[7]), - abi_ulong) != 0) { - goto do_sigsegv; - } /* FIXME this does not match how the kernel handles the FPU in * its sparc64_set_context implementation. In particular the FPU * is only restored if fenab is non-zero in: @@ -501,7 +500,6 @@ void sparc64_get_context(CPUSPARCState *env) struct target_ucontext *ucp; target_mc_gregset_t *grp; target_mcontext_t *mcp; - abi_ulong fp, i7, w_addr; int err; unsigned int i; target_sigset_t target_set; @@ -553,6 +551,15 @@ void sparc64_get_context(CPUSPARCState *env) __put_user(env->gregs[5], &((*grp)[SPARC_MC_G5])); __put_user(env->gregs[6], &((*grp)[SPARC_MC_G6])); __put_user(env->gregs[7], &((*grp)[SPARC_MC_G7])); + + /* + * Note that unlike the kernel, we didn't need to mess with the + * guest register window state to save it into a pt_regs to run + * the kernel. So for us the guest's O regs are still in WREG_O* + * (unlike the kernel which has put them in UREG_I* in a pt_regs) + * and the fp and i7 are still in WREG_I6 and WREG_I7 and don't + * need to be fished out of userspace memory. + */ __put_user(env->regwptr[WREG_O0], &((*grp)[SPARC_MC_O0])); __put_user(env->regwptr[WREG_O1], &((*grp)[SPARC_MC_O1])); __put_user(env->regwptr[WREG_O2], &((*grp)[SPARC_MC_O2])); @@ -562,18 +569,8 @@ void sparc64_get_context(CPUSPARCState *env) __put_user(env->regwptr[WREG_O6], &((*grp)[SPARC_MC_O6])); __put_user(env->regwptr[WREG_O7], &((*grp)[SPARC_MC_O7])); - w_addr = TARGET_STACK_BIAS + env->regwptr[WREG_O6]; - fp = i7 = 0; - if (get_user(fp, w_addr + offsetof(struct target_reg_window, ins[6]), - abi_ulong) != 0) { - goto do_sigsegv; - } - if (get_user(i7, w_addr + offsetof(struct target_reg_window, ins[7]), - abi_ulong) != 0) { - goto do_sigsegv; - } - __put_user(fp, &(mcp->mc_fp)); - __put_user(i7, &(mcp->mc_i7)); + __put_user(env->regwptr[WREG_FP], &(mcp->mc_fp)); + __put_user(env->regwptr[WREG_I7], &(mcp->mc_i7)); { uint32_t *dst = ucp->tuc_mcontext.mc_fpregs.mcfpu_fregs.sregs; From patchwork Tue Nov 10 08:30:34 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Vivier X-Patchwork-Id: 1397421 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=vivier.eu Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CVh1D0gl7z9sPB for ; Tue, 10 Nov 2020 19:32:00 +1100 (AEDT) Received: from localhost ([::1]:39912 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcP4H-0000mi-VL for incoming@patchwork.ozlabs.org; Tue, 10 Nov 2020 03:31:57 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcP38-0000lf-Kn for qemu-devel@nongnu.org; Tue, 10 Nov 2020 03:30:48 -0500 Received: from mout.kundenserver.de ([212.227.17.10]:45743) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcP33-000733-Tg for qemu-devel@nongnu.org; Tue, 10 Nov 2020 03:30:46 -0500 Received: from localhost.localdomain ([82.252.154.198]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1M89P3-1kgXeO1PJT-005GG9; Tue, 10 Nov 2020 09:30:39 +0100 From: Laurent Vivier To: qemu-devel@nongnu.org Subject: [PULL 3/3] linux-user/sparc: Don't zero high half of PC, NPC, PSR in sigreturn Date: Tue, 10 Nov 2020 09:30:34 +0100 Message-Id: <20201110083034.224832-4-laurent@vivier.eu> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20201110083034.224832-1-laurent@vivier.eu> References: <20201110083034.224832-1-laurent@vivier.eu> MIME-Version: 1.0 X-Provags-ID: V03:K1:fTEwE+mQ3Xkaj3i71upGpFf6necyc4LgO4712/yqeVEG0otH7gO 7U0g3Zd2TuNjOooYKHiNV3u/SuvVOxmWgdGv39NxkxEOsbA1mnXkq08yGdbKoOL5btM73F9 pGiCG2uG1xIBswAgEph9ebuswLyqY2xYkcYkyEbfvhnsVh7OGcMx5n55KYoUdmmWUtl0VTe NpTpSTM7DQGlVB2VA6TJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:ksDZc8uw4Wk=:jJLFMKcK/+CVtb2JE4+UZ8 ZOcdvCuh5lqAZhcuCMBu3ji22ElpTwupe4v4YSfRTUHhX2OOeDRk+0tLXOGc1ImhdUxRZP/Jq a6AlJJNvbsMIL352SDvw5HnX2myxrjSTSwt3C2Gcs0BrnXqdVUb7TzQTePcl7JeNqgPQX3B16 IX1OhBCG3ybRmOweOW9zAGhmOIxnQQMOut8XG8Nru1DJklZ6C0mVhQy1gQ9T72Y6s9EPYtY3V hjJMD6J2IlWztvKkqNjUPurAZcsGanFISfuBpS0Wvue6Dko4zUJEahimyztDaE/28PbnECNfp e/ecumXQ24Gm4Z0uG0NRMKsXoMcrnd/skQDoh11iEGwND9iDBNcqumPi6nOfaQsYEJ8W6Az5u xbNKFJHDs23WhXpJSLIQMpSzLX2FIww6kprmd9zOONLOwlGGj06q0MbdnIWUVvq0zgugNhSyw h6nMUd5aNQ== Received-SPF: none client-ip=212.227.17.10; envelope-from=laurent@vivier.eu; helo=mout.kundenserver.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/10 03:30:38 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Richard Henderson , Laurent Vivier Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" From: Peter Maydell The function do_sigreturn() tries to store the PC, NPC and PSR in uint32_t local variables, which implicitly drops the high half of these fields for 64-bit guests. The usual effect was that a guest which used signals would crash on return from a signal unless it was lucky enough to take it while the PC was in the low 4GB of the address space. In particular, Debian /bin/dash and /bin/bash would segfault after executing external commands. Use abi_ulong, which is the type these fields all have in the __siginfo_t struct. Signed-off-by: Peter Maydell Reviewed-by: Richard Henderson Message-Id: <20201105212314.9628-4-peter.maydell@linaro.org> Signed-off-by: Laurent Vivier --- linux-user/sparc/signal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/linux-user/sparc/signal.c b/linux-user/sparc/signal.c index c315704b3895..d12adc8e6ff9 100644 --- a/linux-user/sparc/signal.c +++ b/linux-user/sparc/signal.c @@ -247,7 +247,7 @@ long do_sigreturn(CPUSPARCState *env) { abi_ulong sf_addr; struct target_signal_frame *sf; - uint32_t up_psr, pc, npc; + abi_ulong up_psr, pc, npc; target_sigset_t set; sigset_t host_set; int i;