From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6292 invoked by alias); 31 Mar 2014 07:16:27 -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 6281 invoked by uid 89); 31 Mar 2014 07:16:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 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; Mon, 31 Mar 2014 07:16:25 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2V7GORY009177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 31 Mar 2014 03:16:24 -0400 Received: from [10.36.116.20] (ovpn-116-20.ams2.redhat.com [10.36.116.20]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2V7GN8Q024880; Mon, 31 Mar 2014 03:16:23 -0400 Subject: Re: [PATCH] implement support for "enum class" From: Mark Wielaard To: Tom Tromey Cc: gdb-patches@sourceware.org In-Reply-To: <87y4zrhtj0.fsf@fleche.redhat.com> References: <1395951111-8189-1-git-send-email-tromey@redhat.com> <1396005664.3824.70.camel@bordewijk.wildebeest.org> <87y4zrhtj0.fsf@fleche.redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 31 Mar 2014 07:16:00 -0000 Message-ID: <1396250182.31641.40.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00689.txt.bz2 Hi Tom, On Sun, 2014-03-30 at 22:38 -0600, Tom Tromey wrote: > >>>>> "Mark" == Mark Wielaard writes: > Mark> If the test is right then I think you don't want to print the underlying > Mark> type if DW_AT_enum_class is set and the enum has type safe semantics? > > I'm not totally sure what to do. It seems that without extra > information there is no perfect answer. > > At least this code should (most likely) only print the ": type" part for > C++, not for C. That was an oversight in the original patch. This may > omit some information from the C case, but on the other hand at least > the output won't be gratuitously non-C. Yes, that seems to be the right way, if you want to print the type as something that is a valid expression. Note that the underlying type in C is almost always just "int", except when using -fshort-enums then GCC uses the smallest representation like C++. > I was anticipating that GCC would emit an unnamed type for the > underlying type in the case where the underlying type is not specified > in the source. However I can see why it would not necessarily do this, > and certainly there's no requirement in DWARF along these lines. Funny. You pointed out my original patch accidentally did this sometimes. Causing lots of extra base type DIEs. I indeed fixed this to emit the already known base type in the CU (which often is the named int base type) to reduce duplication. I think this is the correct thing to do. > One option might be to have the DWARF reader omit the underlying type > when the type it guessed from the enum values agreed with the type > specified in DW_AT_type. Of course that's just a heuristic. It's > perhaps better, I think, to just always emit the bits even if they are > in some sense redundant. > > In C++11, whether an underlying type is specified is orthogonal to > whether the enum is an "enum class". "enum x : short" is perfectly ok. Aha, you are right. And there is no way to know from the DWARF whether the compiler derived the underlying type or the user explicitly defined it. I am also not sure what the right thing to do is here. But I think it makes sense to make printing it depend on the language used and always print it when the language supports "derived enums" whether the user explicitly defined it or it was guessed by the compiler. It is an valid expression in any case and the GDB user might appreciate the extra info (in the case of C++). Cheers, Mark