From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62002 invoked by alias); 13 Dec 2017 21:22:24 -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 61993 invoked by uid 89); 13 Dec 2017 21:22:23 -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= 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 21:22:22 +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 6A8AD81DE6; Wed, 13 Dec 2017 21:22:21 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 28CB76C51F; Wed, 13 Dec 2017 21:22:14 +0000 (UTC) Subject: Re: [PATCH v5 2/2] Implement pahole-like 'ptype /o' option To: Sergio Durigan Junior 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> <87k1xqicv0.fsf@redhat.com> Cc: GDB Patches , Tom Tromey , Eli Zaretskii , Simon Marchi , Keith Seitz From: Pedro Alves Message-ID: Date: Wed, 13 Dec 2017 21:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87k1xqicv0.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-12/txt/msg00322.txt.bz2 On 12/13/2017 08:36 PM, Sergio Durigan Junior wrote: > On Wednesday, December 13 2017, I wrote: >> OK, I'll confirm on PPC64BE. Thanks. > > 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} > You didn't initialize e.a5, so even the x86_64 version looks wrong at first. You're seeing stack/register garbage in the padding holes. You should make that "e" a global to make sure all its underlying bytes are clear, including padding. Or memset it. The former is easier. a2, a3 and a4 in the PPC64 version do look odd. Though maybe that's something do to with the expression you used. Does it make a difference if you initialize all fields with separate statements, like: e.a1 = -1; e.a2 = -1; etc. > As for "ptype /o", the offsets printed on x86_64 and PPC64BE are the > same: So it sounds like we could remove the x86-64 check in the testcase and let it run on all lp64 targets? Does it pass cleanly on PPC64? Thanks, Pedro Alves