From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10365 invoked by alias); 23 Jun 2014 16:27:57 -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 10354 invoked by uid 89); 23 Jun 2014 16:27:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 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 16:27:55 +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 s5NGRsVQ000920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 23 Jun 2014 12:27:54 -0400 Received: from barimba (ovpn-113-103.phx2.redhat.com [10.3.113.103]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5NGRqnk029900 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Jun 2014 12:27:53 -0400 From: Tom Tromey To: Mark Wielaard Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] DWARFv5. Handle DW_TAG_atomic_type _Atomic type modifier. References: <1403432716-8344-1-git-send-email-mjw@redhat.com> Date: Mon, 23 Jun 2014 16:27:00 -0000 In-Reply-To: <1403432716-8344-1-git-send-email-mjw@redhat.com> (Mark Wielaard's message of "Sun, 22 Jun 2014 12:25:16 +0200") Message-ID: <874mzb7fqv.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-06/txt/msg00821.txt.bz2 >>>>> "Mark" == Mark Wielaard writes: Mark> This prototype patch matches the experimental patch to GCC: Mark> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01677.html Thanks, Mark. Mark> Since there is not even a draft of DWARFv5 I don't recommend adopting Mark> this patch. All details may change in the future. I am mainly doing it Mark> to give better feedback on the DWARFv5 proposals (in this case the Mark> feedback would be that it is unfortunate we cannot easily do this as a Mark> vendor extension with DW_TAG_GNU_atomic_type since that would break Mark> backward compatibility). I don't understand this bit. It's reasonably normal to add a new GNU tag. Mark> Is there a recommended way for doing/keeping these kind of Mark> speculative patches? Just hosting it on a public git somewhere. I suppose we could resurrect archer.git, though there are plenty of hosting services now. Some nits follow. The patch looks good overall. Mark> diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c Mark> index ba64256..50bc194 100644 Mark> --- a/gdb/dwarf2read.c Mark> +++ b/gdb/dwarf2read.c Mark> @@ -4286,9 +4286,9 @@ error_check_comp_unit_head (struct comp_unit_head *header, Mark> bfd *abfd = get_section_bfd_owner (section); Mark> const char *filename = get_section_file_name (section); Mark> - if (header->version != 2 && header->version != 3 && header->version != 4) Mark> + if (header->version < 2 || header->version > 5) Mark> error (_("Dwarf Error: wrong version in compilation unit header " Mark> - "(is %d, should be 2, 3, or 4) [in module %s]"), header->version, Mark> + "(is %d, should be 2, 3, 4 or 5) [in module %s]"), header->version, Normally this should be a separate patch. For one thing, then it could go in even if _Atomic doesn't appear in DWARF 5. Mark> +static struct type * Mark> +read_tag_atomic_type (struct die_info *die, struct dwarf2_cu *cu) gdb requires a comment before a new function. Mark> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-atomic.S b/gdb/testsuite/gdb.dwarf2/dw2-atomic.S FWIW it's simpler and better to write this using the DWARF assembler in the test suite. enum-type.exp is an ok example of the kind of thing you'd want to do -- just describing a new type and then testing it with ptype. Using the DWARF assembler would let you drop the x86-64-only part of the test. Mark> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-error.exp b/gdb/testsuite/gdb.dwarf2/dw2-atomic.exp Hah, this confused me for a while, until I realized that git was treating it like a copy. Mark> # First test that reading symbols fails. Mark> gdb_test "file $binfile" \ Mark> - "Reading symbols.*Dwarf Error: wrong version in compilation unit header .is 153, should be 2, 3, or 4.*" \ Mark> + "Reading symbols.*Dwarf Error: wrong version in compilation unit header .is 153, should be 2, 3, 4 or 5.*" \ Mark> "file $testfile" Should be in the separate DWARF 5 patch. Tom