From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11284 invoked by alias); 23 Jun 2014 21:34:06 -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 11275 invoked by uid 89); 23 Jun 2014 21:34:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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, 23 Jun 2014 21:34:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5NLY1o2015610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Jun 2014 17:34:02 -0400 Received: from [10.36.116.50] (ovpn-116-50.ams2.redhat.com [10.36.116.50]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5NLY0Ka009608; Mon, 23 Jun 2014 17:34:00 -0400 Subject: Re: [PATCH] DWARFv5. Handle DW_TAG_atomic_type _Atomic type modifier. From: Mark Wielaard To: Eric Christopher Cc: Tom Tromey , gdb-patches In-Reply-To: References: <1403432716-8344-1-git-send-email-mjw@redhat.com> <874mzb7fqv.fsf@fleche.redhat.com> <1403543197.3970.49.camel@bordewijk.wildebeest.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Jun 2014 21:34:00 -0000 Message-ID: <1403559239.3970.69.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00830.txt.bz2 On Mon, 2014-06-23 at 11:01 -0700, Eric Christopher wrote: > FWIW a new vendor tag, even for such as this, would be a better > solution. The numbers you choose for any attributes, if the proposals > are accepted, would not necessarily be the same ones you chose. That > confusion between numbers in consumers is worse than an unknown tag > IMO. Most certainly agreed. I normally work on other DWARF consumers and I know all too well that whatever GCC/GDB adopts is what the rest of the toolchain ends up having to support. The goal of the prototype patches wasn't to get them integrated/adopted before DWARFv5 is finalized. The goal was just to create something to see if it is doable (both GCC and GDB seem to have nice datastructures already setup, so even for someone like me without any prior knowledge of either program it was easy to add) and give feedback on the proposal to see if it is worth it to adopt for the next DWARF spec. I'll think the answer is yes and I'll keep the patches around. So that if there is a new DWARF standard version then we have an implementation for the GNU toolchain as soon as it is final. But there isn't even a first working draft at this point, just a bunch of proposals which might or might not be adopted in their current or in some completely different form. So these patches might not be integrated till next year. For anything that does get integrated into GCC or GDB before DWARFv5 is final we should certainly use a GNU vendor extension so that the rest of the toolchain can easily adopt it. But that won't be possible in the current form since DWARF type qualifier tags aren't vendor extensible. And I don't know if anybody even needs it right now. Maybe if it is useful for the GDB/GCC compiler expression effort we could create a GNU vendor extension? Cheers, Mark