From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69451 invoked by alias); 13 Dec 2017 21:34:56 -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 69438 invoked by uid 89); 13 Dec 2017 21:34:56 -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:34:54 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9EFC05FD67; Wed, 13 Dec 2017 21:34:53 +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 764157EE7B; Wed, 13 Dec 2017 21:34:53 +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> <87k1xqicv0.fsf@redhat.com> Date: Wed, 13 Dec 2017 21:34:00 -0000 In-Reply-To: (Pedro Alves's message of "Wed, 13 Dec 2017 21:22:14 +0000") Message-ID: <87fu8eia6b.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00324.txt.bz2 On Wednesday, December 13 2017, Pedro Alves wrote: > 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. > >>=20 >> 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: >>=20 >> struct tyu >> { >> int a1 : 1; >>=20 >> int a2 : 3; >>=20 >> int a3 : 23; >>=20 >> char a4 : 2; >>=20 >> int64_t a5; >>=20 >> int a6 : 5; >>=20 >> int64_t a7 : 3; >> }; >>=20 >> int >> main (int argc, char *argv[]) >> { >> struct tyu e; >>=20 >> e.a1 =3D e.a2 =3D e.a3 =3D e.a4 =3D e.a6 =3D e.a7 =3D -1; >>=20 >> return 0; >> } >>=20 >> After stopping GDB at the "return 0;" line, here's what we see when we >> print "e" on x86_64: >>=20 >> (gdb) p e >> $1 =3D {a1 =3D -1, a2 =3D -1, a3 =3D -1, a4 =3D -1 '\377', a5 =3D 1407= 37488344880, a6 =3D -1, a7 =3D -1} >>=20 >> While on PPC64BE: >>=20 >> (gdb) p e >> $1 =3D {a1 =3D -1, a2 =3D 3, a3 =3D 3, a4 =3D 3 '\003', a5 =3D 7036753= 6153528, a6 =3D -1, a7 =3D -1} >>=20 > > 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. I should have initialized e.a5 to 0 in order to make the problem easier to spot. I did that now: $1 =3D {a1 =3D -1, a2 =3D 3, a3 =3D 3, a4 =3D 3 '\003', a5 =3D 0, a6 =3D -1= , a7 =3D -1} > 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 =3D -1; > e.a2 =3D -1; > etc. After memset'ing the variable to 0, and separating all assignments, I get: [sergiodj@gcc1-power7 build-gdb]$ g++ -g ptype-offsets.cc=20 ptype-offsets.cc: In function =E2=80=98int main(int, char**)=E2=80=99: ptype-offsets.cc:170:8: warning: large integer implicitly truncated to unsi= gned type [-Woverflow] e.a4 =3D -1; ^ $1 =3D {a1 =3D -1, a2 =3D -1, a3 =3D -1, a4 =3D 3 '\003', a5 =3D 0, a6 =3D = -1, a7 =3D -1} After changing the declaration of a4 to "signed char a4 : 2;": $1 =3D {a1 =3D -1, a2 =3D -1, a3 =3D -1, a4 =3D -1 '\377', a5 =3D 0, a6 =3D= -1, a7 =3D -1} >> 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=20 > testcase and let it run on all lp64 targets? Does it pass > cleanly on PPC64? I'm checking this right now, because I have to readjust the test due to the changes in the output format. --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/