From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18220 invoked by alias); 23 Jun 2014 18:01:38 -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 18207 invoked by uid 89); 23 Jun 2014 18:01:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f178.google.com Received: from mail-vc0-f178.google.com (HELO mail-vc0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 23 Jun 2014 18:01:06 +0000 Received: by mail-vc0-f178.google.com with SMTP id ij19so6336535vcb.23 for ; Mon, 23 Jun 2014 11:01:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.248.209 with SMTP id yo17mr1888378vdc.60.1403546464258; Mon, 23 Jun 2014 11:01:04 -0700 (PDT) Received: by 10.58.134.37 with HTTP; Mon, 23 Jun 2014 11:01:04 -0700 (PDT) In-Reply-To: <1403543197.3970.49.camel@bordewijk.wildebeest.org> References: <1403432716-8344-1-git-send-email-mjw@redhat.com> <874mzb7fqv.fsf@fleche.redhat.com> <1403543197.3970.49.camel@bordewijk.wildebeest.org> Date: Mon, 23 Jun 2014 18:01:00 -0000 Message-ID: Subject: Re: [PATCH] DWARFv5. Handle DW_TAG_atomic_type _Atomic type modifier. From: Eric Christopher To: Mark Wielaard Cc: Tom Tromey , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00827.txt.bz2 > It is certainly reasonable to add new vendor attributes or tags, but > only for "independent" tags or attributes that consumers can easily > ignore if they aren't recognized. There is no mechanism for introducing > new vendor type qualifier tags like these in DWARF. The issue is that a > consumer cannot detect that a tag is just a type qualifier which can be > ignored if not recognized (all type qualifiers do use DW_AT_type to > point to the underlying type, but so do other non-qualifier tags that > have completely different semantics). So if we would add a vendor tag > and GCC starts annotating/wrapping other type tags with > DW_TAG_GNU_atomic_type then consumers will start failing to find the > underlying type (I already had to patch up various consumers when I > added DW_TAG_restrict_type, which has been standard since DWARFv3). So > if we would introduce a vendor extension to mark atomic types, then it > would have to work differently from the proposed type qualifier tag. > 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. -eric