From patchwork Thu Jul 28 20:36:19 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Laurent Vivier X-Patchwork-Id: 653876 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3s0kFb0WZ4z9t29 for ; Fri, 29 Jul 2016 06:37:54 +1000 (AEST) Received: from localhost ([::1]:55550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSs3v-0007Un-4n for incoming@patchwork.ozlabs.org; Thu, 28 Jul 2016 16:37:47 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSs31-0006zm-F2 for qemu-devel@nongnu.org; Thu, 28 Jul 2016 16:36:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSs2j-0006EI-V7 for qemu-devel@nongnu.org; Thu, 28 Jul 2016 16:36:51 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:62351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSs2j-0006Dy-Gh for qemu-devel@nongnu.org; Thu, 28 Jul 2016 16:36:33 -0400 Received: from [192.168.100.1] ([78.238.229.36]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0Lst7y-1bHLg41Ycs-012VYz; Thu, 28 Jul 2016 22:36:22 +0200 To: Peter Maydell , qemu-devel@nongnu.org References: <1469707079-9049-1-git-send-email-peter.maydell@linaro.org> From: Laurent Vivier Message-ID: Date: Thu, 28 Jul 2016 22:36:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1469707079-9049-1-git-send-email-peter.maydell@linaro.org> X-Provags-ID: V03:K0:KFoqgraVh/QCTL6tBwcu/t2OPLhXOV0KC8OuE0rf+txHbm+rd3b RhVjRCh17MpiyXEwOJzm22537f4mRvkbdhFJJRLeL+kEOKMgXL4IEzFwSt2hFnG2H3edHhH 6hxOTSFscOSWgDGuaLiuHRRssjqJmt9rBC6eFcH95gsr0U0lOhfniF//+4TmcnX0g0Y/r4z SZowONpQdit3z6rHFTEDg== X-UI-Out-Filterresults: notjunk:1; V01:K0:VjJ1GUpRTro=:aXEIF2KypNR1C+y08x9bG2 HNfxNv6nT6X+YE7Lm4+MQVsmeyn3xTVTrP67/lDCUcmQLxHairPhcSp87SZR8IwUGTt23zXhD +rlSeooFFv+hdYjgfPC9tehmJUYzGbVf4p64ruSVJKfNhy9ea6/FeYr2WDzkjyBwsb89j+5D8 YPEzPSiPmrmN8WROcTA8qKIPNa26YZ2L+UdfLpG8O2dLQEGGFf6cgtv5U8sIGP1qgH5MvY1GK TtmJ2ov7WdqTjAy5m3/DRIgW2J/swcL24T9toXMpLKBIcSwJWHnR+PMs8RAOhF7zAPE5Pkoqg 2Rp/aq+0XT/A0Pgq63T498zv0puYlj6GrLDc9TYJsBmgH6RlTGJCrDS6bjTWEZ+vN0soR/O8+ FyAkYq8K7Ev1rLb10NpfySFFDZD25N6ymjrLS8eceMVZ0GcdVryssqiEpxCvJIlzkpY+JlAcX nqraIH+xA3GSyaMZX0WwGnajtL0DJOJRJTqsvt7wvZGtlBYmjdSo71uqjQDbRPvAYhvJTZtNN Wtt9l0xaOwolbicO3sp5KSLTEzNLgA1lVaDHa7w+H3Nf1WV/IfBT1sw7yF+DStBAQREFLvHMv NqykfKuv9baoqX9Uk9ulFzfusTDOecjYxFG833iGwdlZ6sb21y9vSkhddaTSxIOUBhBJUoOYD tS7AwLxiSP5YR7gfVNfxxtRK3GUSIZbRmaewuIY5S/RbvaN023klLsGuUCzO8U8IE88DeLBPv /kxT0rJ9i6MeTF93 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.126.135 Subject: Re: [Qemu-devel] [PATCH] linux-user: Use correct alignment for long long on i386 guests X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Riku Voipio , Icenowy Zheng , patches@linaro.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Le 28/07/2016 à 13:57, Peter Maydell a écrit : > For i386, the ABI specifies that 'long long' (8 byte values) > need only be 4 aligned, but we were requiring them to be > 8-aligned. This meant we were laying out the target_epoll_event > structure wrongly. Add a suitable ifdef to abitypes.h to > specify the i386-specific alignment requirement. gdb qemu-i386 (gdb) p &(((struct target_epoll_event *)0)->data) $1 = (target_epoll_data_t *) 0x8 whereas: gdb qemu-x86_64 (gdb) p &(((struct target_epoll_event *)0)->data) $1 = (target_epoll_data_t *) 0x4 I've checked on real systems x86_64/i386: ----- #include int main(void) { volatile struct epoll_event e; e.events = 0; } ---- (gdb) p &(((struct epoll_event *)0)->data) $1 = (epoll_data_t *) 0x4 but on ppc64, I have (gdb) p &(((struct epoll_event *)0)->data) $1 = (epoll_data_t *) 0x8 In fact, the structure should be packed in both cases, something like: #define TARGET_EPOLL_PACKED on my Fedora systems x86_64/i386: /usr/include/bits/epoll.h #define __EPOLL_PACKED __attribute__ ((__packed__)) /usr/include/sys/epoll.h struct epoll_event { uint32_t events; /* Epoll events */ epoll_data_t data; /* User data variable */ } __EPOLL_PACKED; but I don't understand why in linux source tree we have #ifdef __x86_64__ #define EPOLL_PACKED __attribute__((packed)) #else #define EPOLL_PACKED #endif struct epoll_event { __u32 events; __u64 data; } EPOLL_PACKED; Laurent --- a/linux-user/syscall_defs.h +++ b/linux-user/syscall_defs.h @@ -2562,7 +2562,7 @@ struct target_mq_attr { #define FUTEX_CMD_MASK ~(FUTEX_PRIVATE_FLAG | FUTEX_CLOCK_REALTIME) #ifdef CONFIG_EPOLL -#if defined(TARGET_X86_64) +#if defined(TARGET_X86_64) || defined(TARGET_I386) #define TARGET_EPOLL_PACKED QEMU_PACKED #else