From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73538 invoked by alias); 13 Dec 2017 20:36:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 73528 invoked by uid 89); 13 Dec 2017 20:36:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=003 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Dec 2017 20:36:54 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CCF7E5F7A6; Wed, 13 Dec 2017 20:36:52 +0000 (UTC) Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8204E6C21F; Wed, 13 Dec 2017 20:36:52 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Tom Tromey , Eli Zaretskii , Simon Marchi , Keith Seitz Subject: Re: [PATCH v5 2/2] Implement pahole-like 'ptype /o' option References: <20171121160709.23248-1-sergiodj@redhat.com> <20171213031724.22721-1-sergiodj@redhat.com> <20171213031724.22721-3-sergiodj@redhat.com> <614d15fc-3793-8a55-b7cc-67570e8c46d3@redhat.com> <87r2ryk0ux.fsf@redhat.com> Date: Wed, 13 Dec 2017 20:36:00 -0000 In-Reply-To: <87r2ryk0ux.fsf@redhat.com> (Sergio Durigan Junior's message of "Wed, 13 Dec 2017 12:13:10 -0500") Message-ID: <87k1xqicv0.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00321.txt.bz2 On Wednesday, December 13 2017, I wrote: > On Wednesday, December 13 2017, Pedro Alves wrote: > >> I'm mildly worried about whether the bitfield handling is working >> correctly on big endian machines. We may want to lift this >> x86-64-only restriction, by using e.g., alignas(N) or >> __attribute__((aligned(N)) to take care of most of the differences >> between architectures and end up with few per-arch code in >> the .exp. But I'm fine with starting with only x86-64 if you >> confirm manually on e.g., a big endian PPC64 machine on the >> compile farm, and we can extend the testcase in that direction >> after this is merged. > > OK, I'll confirm on PPC64BE. It seems like the algorithm for calculating bitfield offsets is not working correctly on BE machines. This is not only for "ptype /o", but also for regular print commands. For example, consider this test: struct tyu { int a1 : 1; int a2 : 3; int a3 : 23; char a4 : 2; int64_t a5; int a6 : 5; int64_t a7 : 3; }; int main (int argc, char *argv[]) { struct tyu e; e.a1 = e.a2 = e.a3 = e.a4 = e.a6 = e.a7 = -1; return 0; } After stopping GDB at the "return 0;" line, here's what we see when we print "e" on x86_64: (gdb) p e $1 = {a1 = -1, a2 = -1, a3 = -1, a4 = -1 '\377', a5 = 140737488344880, a6 = -1, a7 = -1} While on PPC64BE: (gdb) p e $1 = {a1 = -1, a2 = 3, a3 = 3, a4 = 3 '\003', a5 = 70367536153528, a6 = -1, a7 = -1} As for "ptype /o", the offsets printed on x86_64 and PPC64BE are the same: x86_64: /* offset | size */ type = struct tyu { /* 0:31 | 4 */ int a1 : 1; /* 0:28 | 4 */ int a2 : 3; /* 0: 5 | 4 */ int a3 : 23; /* 3: 3 | 1 */ char a4 : 2; /* XXX 3-bit hole */ /* XXX 4-byte hole */ /* 8 | 8 */ int64_t a5; /* 16:27 | 4 */ int a6 : 5; /* 16:56 | 8 */ int64_t a7 : 3; /* total size (bytes): 24 */ } PPC64BE: /* offset | size */ type = struct tyu { /* 0:31 | 4 */ int a1 : 1; /* 0:28 | 4 */ int a2 : 3; /* 0: 5 | 4 */ int a3 : 23; /* 3: 3 | 1 */ char a4 : 2; /* XXX 3-bit hole */ /* XXX 4-byte hole */ /* 8 | 8 */ int64_t a5; /* 16:27 | 4 */ int a6 : 5; /* 16:56 | 8 */ int64_t a7 : 3; /* total size (bytes): 24 */ } -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/