From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30706 invoked by alias); 27 Feb 2014 10:30:40 -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 30690 invoked by uid 89); 27 Feb 2014 10:30:39 -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 ESMTP; Thu, 27 Feb 2014 10:30:38 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1RAUYhn024139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Feb 2014 05:30:34 -0500 Received: from [10.36.116.104] (ovpn-116-104.ams2.redhat.com [10.36.116.104]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1RAUVvL006815; Thu, 27 Feb 2014 05:30:32 -0500 Subject: Re: [RFA/DWARF] Set enum type "flag_enum" and "unsigned" flags at type creation. From: Mark Wielaard To: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20140226183157.GF4348@adacore.com> References: <1390796357-3739-1-git-send-email-brobecker@adacore.com> <1392820455.21975.235.camel@bordewijk.wildebeest.org> <1392823115.21975.238.camel@bordewijk.wildebeest.org> <20140226183157.GF4348@adacore.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 27 Feb 2014 10:30:00 -0000 Message-ID: <1393497031.8933.208.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00818.txt.bz2 On Wed, 2014-02-26 at 10:31 -0800, Joel Brobecker wrote: > I finally had some time to test this patch, and unfortunately, > it does introduce some regression (in Ada). For instance in > homonym.exp: Sorry, I didn't have gcc-gnat installed and so missed this. I have it installed now. BTW. Are there any overviews of what are expected results? For make check RUNTESTFLAGS='--directory gdb.ada' I get: === gdb Summary === # of expected passes 490 # of unexpected failures 29 # of unexpected successes 8 # of expected failures 2 # of known failures 1 # of unsupported tests 3 Is that reasonable? The amount of failures seems a bit high. The testsuite is not supposed to be (near) zero-fail? > type Integer_Range is new Integer range -100 .. 100; > subtype Local_Type is Integer_Range; > > This is what GDB would print afterwards: > > (gdb) ptype local_type > type = range 4294967196 .. 100 > > The lower bound should be -100. The debugging info is generated > as follow: > > <2><80>: Abbrev Number: 2 (DW_TAG_subrange_type) > <81> DW_AT_lower_bound : 0xffffff9c > <85> DW_AT_upper_bound : 100 > <86> DW_AT_name : (indirect string, offset: 0x76): homonym__get_value__local_type___XDLU_100m__100 > <8a> DW_AT_type : <0x37> > > And the corresponding abbrev gives the form: > > 2 DW_TAG_subrange_type [no children] > DW_AT_lower_bound DW_FORM_data4 > DW_AT_upper_bound DW_FORM_data1 > DW_AT_name DW_FORM_strp > DW_AT_type DW_FORM_ref4 > DW_AT value: 0 DW_FORM value: 0 > > It's the dreaded DW_FORM_dataN form... And unfortunately, I get the same > representation with pre-versions of GCC 4.9, so it looks like we're not > going to be able to remove that bit anytime soon :-(. Grrr and sigh. Why does GCC do that? Encoding the negative lower bound like that actually takes up more space than simply using DW_FORM_sdata. The comment in the GCC sources even says this is suboptimal: /* Otherwise represent the bound as an unsigned value with the precision of its type. The precision and signedness of the type will be necessary to re-interpret it unambiguously. */ Luckily it seems GCC only does this when adding bounds info. But it does seem we are stuck with it for now :{ I'll see if I can fix GCC so one day day in the far, far, future this hack won't be necessary. Cheers, Mark