From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2944 invoked by alias); 29 Sep 2014 15:17:26 -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 2928 invoked by uid 89); 29 Sep 2014 15:17:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 29 Sep 2014 15:17:23 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8TFHIGa011102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Sep 2014 11:17:19 -0400 Received: from bordewijk.wildebeest.org (ovpn-116-77.ams2.redhat.com [10.36.116.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8TFHGiS027533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Sep 2014 11:17:17 -0400 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id 400178143831; Mon, 29 Sep 2014 17:17:16 +0200 (CEST) Message-ID: <1412003836.5933.17.camel@bordewijk.wildebeest.org> Subject: Re: [PATCH] DWARFv5 DW_TAG_aligned_type. From: Mark Wielaard To: Joel Brobecker Cc: gdb-patches@sourceware.org, Tom Tromey Date: Mon, 29 Sep 2014 15:17:00 -0000 In-Reply-To: <20140730165934.GD14672@adacore.com> References: <1404944457-4500-1-git-send-email-mjw@redhat.com> <20140711144227.GB4888@adacore.com> <1405635556.17759.205.camel@bordewijk.wildebeest.org> <1405635906.17759.210.camel@bordewijk.wildebeest.org> <20140730165934.GD14672@adacore.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2014-09/txt/msg00836.txt.bz2 Hi Joel, My apologies it took so long before I made time to look at your example. On Wed, 2014-07-30 at 09:59 -0700, Joel Brobecker wrote: > > Could you post an example Ada source code example so I can test a > > bit how my gcc and gdb patches interact for an user aligned Ada > > type? >=20 > Here it is (credits to Eric Botcazou): >=20 > package P is >=20 > type My_Integer is new Integer; > for My_Integer'Alignment use 1; >=20 > C : Character; > I : My_Integer; >=20 > end P; >=20 > Save the code in a file called p.ads, and then compile it using: >=20 > % gcc -c -g p.ads Thanks. I used https://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Running-a-Program-with-Multiple= -Units.html to play a bit with it and get something I could inspect under G= DB. I think I see now what you mean with not having alignment needing to be stricter for sub types in Ada. type Another_Integer is new My_Integer; for Another_Integer'Alignment use 8; type Your_Integer is new Another_Integer; for Your_Integer'Alignment use 4; C : Character; I : My_Integer; C2 : Character; I2 : Another_Integer; C3 : Character; I3 : Your_Integer; Adding some variables of different subtypes shows the compiler uses the actual user defined aligned, not the the strictest alignment possible according to the type hierarchy when multiple are defined. On the other hand, in Ada you don't seem to be able to add the alignment aspect for a specific type multiple times as you can in C. But at least usage of "strictest alignment" wording can be a little confusing in this case. Something that does surprise me is that ptype in gdb seems to always just give the valid subrange of the variables I, I2, I3, not their actual type. (gdb) ptype P.I3 type =3D range -2147483648 .. 2147483647 While my changes for C types were so that ptype would produce a type that you could in theory just pass into the compiler again to get you the same thing. Is the above a deliberate choice for Ada? Hmmm, it seems the above "type Another_Integer is new My_Integer" construct does not result in any DWARF output that would make it possible to say Another_Integer is a subtype of My_Integer? > Variable "C" is just there to prevent variable "I" from being > default-aligned by accident. >=20 > If you look at the debugging info, you'll find that our variable > is called "p__i". The alignment is handled via putting it inside > a ___PAD struct as a component called "F". Eg: >=20 > .uleb128 0x6 # (DIE (0x70) DW_TAG_variable) > .long .LASF1 # DW_AT_name: "p__i" > .long 0x1d # DW_AT_type >=20 > Following the type of that variable gives us: >=20 > .uleb128 0x2 # (DIE (0x1d) DW_TAG_structure_type) > .long .LASF5 # DW_AT_name: "p__my_integer___PAD" > [...] > .uleb128 0x3 # (DIE (0x29) DW_TAG_member) > .ascii "F\0" # DW_AT_name > .long 0x38 # DW_AT_type >=20 > Following then the type of member "F" yields a subrange type: >=20 > .uleb128 0x4 # (DIE (0x38) DW_TAG_subrange_type) > .long 0x80000000 # DW_AT_lower_bound > .long 0x7fffffff # DW_AT_upper_bound > .long .LASF6 # DW_AT_name: "p__my_integer" > .long 0x4b # DW_AT_type > .byte 0x1 # DW_AT_artificial >=20 > ... which points to the integer base type: >=20 > .uleb128 0x5 # (DIE (0x4b) DW_TAG_base_type) > .byte 0x4 # DW_AT_byte_size > .byte 0x5 # DW_AT_encoding > .long .LASF7 # DW_AT_name: "p__Tmy_integerB" > .byte 0x1 # DW_AT_artificial >=20 > Ideally, it'd be better if variable I was described without the PAD > wrapper. We may be headed towards that in the long run, not sure. > But, in the meantime, I think the logical location for adding the > alignment info would probably be the PAD struct? In my example above do see a PAD for some (the first) variable type, but not others. Those just point directly to the named DW_TAG_subrange_type. I think I would expect it to be on the (named) subrange_type either inside or outside the "PAD" (what does that stand for BTW?) struct. Thanks, Mark