From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26411 invoked by alias); 30 Jul 2014 16:59:39 -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 26396 invoked by uid 89); 30 Jul 2014 16:59:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 30 Jul 2014 16:59:37 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0B2E1116333; Wed, 30 Jul 2014 12:59:35 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VBQUeBH9F8hd; Wed, 30 Jul 2014 12:59:34 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id D6382116312; Wed, 30 Jul 2014 12:59:34 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 56B9247811; Wed, 30 Jul 2014 09:59:34 -0700 (PDT) Date: Wed, 30 Jul 2014 18:26:00 -0000 From: Joel Brobecker To: Mark Wielaard Cc: gdb-patches@sourceware.org, Tom Tromey Subject: Re: [PATCH] DWARFv5 DW_TAG_aligned_type. Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1405635906.17759.210.camel@bordewijk.wildebeest.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-07/txt/msg00794.txt.bz2 Hi Mark, > Forgot to ask... > > On Fri, 2014-07-18 at 00:19 +0200, Mark Wielaard wrote: > > On Fri, 2014-07-11 at 07:42 -0700, Joel Brobecker wrote: > > > My only question is regarding the checks for alignments to be stricter > > > than the alignment of their base types. Why are they needed? I am asking > > > because, in Ada, it is allowed to be specifying an alignment which is > > > less strict than the standard alignment. We can ask for byte-aligned > > > integers, for instance. > > 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? Here it is (credits to Eric Botcazou): package P is type My_Integer is new Integer; for My_Integer'Alignment use 1; C : Character; I : My_Integer; end P; Save the code in a file called p.ads, and then compile it using: % gcc -c -g p.ads Variable "C" is just there to prevent variable "I" from being default-aligned by accident. 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: .uleb128 0x6 # (DIE (0x70) DW_TAG_variable) .long .LASF1 # DW_AT_name: "p__i" .long 0x1d # DW_AT_type Following the type of that variable gives us: .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 Following then the type of member "F" yields a subrange type: .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 ... which points to the integer base type: .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 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? -- Joel