From patchwork Thu Mar 20 17:46:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Wielaard X-Patchwork-Id: 332339 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 25F892C0040 for ; Fri, 21 Mar 2014 04:47:08 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; q=dns; s=default; b=PPWEZLV3M2xR cCIdOfLIa1QqXWlZqa+kKcAMpnIN80nEhxwy2wlML99+2on4dXBjDzqpe/7j4V6F lA0tXI8Ws1ohTgsxgCOMEcuwqXB60lncR4zy+WCv0MVgjWRqIabW6j6hQE4Sotwn MvW4buSeGeVDgQunEIuAfDkN/VOLrmU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; s=default; bh=ODAHRBkgCjpPWrvEaa Gwf3gaG9I=; b=ExOs4UMrKq3IhEWaBIxp51am7ZSNF4kSOtj4WCDjps72HJjvla 88ylWGxIQZzyyffFQLogLGdH/Yg1cngkWUc99i1fjhk7Lms+BUEy0AIq2tDmOj1I xKM2D+cZ5vpVYCufagAdopozCE8DS0vjuikFhIj96FBlzd9de61lbqeQk= Received: (qmail 19667 invoked by alias); 20 Mar 2014 17:47:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 19657 invoked by uid 89); 20 Mar 2014 17:47:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 20 Mar 2014 17:46:57 +0000 From: Mark Wielaard To: gcc-patches@gcc.gnu.org Cc: Joel Brobecker , Eric Botcazou , Mark Wielaard Subject: [PATCH] dwarf2out: Represent bound_info with normal constant values if possible. Date: Thu, 20 Mar 2014 18:46:28 +0100 Message-Id: <1395337588-28129-1-git-send-email-mjw@redhat.com> X-Spam-Score: -2.9 (--) Hi, The following patch made it so that 64-bit bounds could be output on 32-bit hosts with DWARF. 2009-07-11 Eric Botcazou * dwarf2out.c (enum dw_val_class): Replace dw_val_class_long_long with dw_val_class_const_double. (struct dw_long_long_struct): Delete. (struct dw_val_struct): Adjust for above change. (add_AT_long_long): Rename into... (add_AT_double): ...this. (print_die): Replace dw_val_class_long_long case with dw_val_class_const_double case. (attr_checksum): Likewise. (same_dw_val_p): Likewise. (size_of_die): Likewise. (value_format): Likewise. (output_die): Likewise. (add_const_value_attribute) : Call add_AT_double instead of add_AT_long_long. (add_bound_info) : Generate the bound as an unsigned value with the precision of its type. http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00653.html This was done by using add_AT_double whenever a constant needed to be output that didn't fit a HOST_WIDE_INT. It also changed the representation of DW_AT_lower_bound and DW_AT_higher_bound when the range did fit in a HOST_WIDE_INT. Up to that patch the range values were added using add_AT_unsigned. But to represent signed values it didn't use add_AT_int, but used an unsigned value with the precision of its type. As the comment added at the time says: "The precision and signedness of the type will be necessary to re-interpret it unambiguously." This is a little unfortunate. Since in other cases this isn't necessary. In particular in all other cases gdb and other DWARF consumers (elfutils at least) assume that when they encounter a DW_FORM_data[1248] they can simply zero-extend it to get the actual constant value. Or that DW_FORM_sdata is used to represent an actual negative constant. (There are a couple of comments about relying on this behavior in both the gcc and gdb sources.) So the patch below makes it so that if HOST_WIDE_INT is wide enough then, depending on whether the range type is signed or not, add_AT_unsigned or add_AT_int is used. This is more efficient for small ranges. And makes it so that the value can be deduced from the DW_FORM by the consumer (which can assume again that DW_FORM_data[1248] are simply zero-extended and that negative constant values are represented by DW_FORM_sdata). I tested this on x86_64 with --enable-languages=c,ada,c++,fortran,java,objc without regressions. I also made sure that the example ada program range is recognized correctly by gdb with this patch. A couple of questions: - Are there more ada DWARF tests? Something like guality used for c/fortran? - What values of HOST_BITS_PER_WIDE_INT are actually supported in GCC? The dwarf2out.c code tries to handle 8, 16, 32 and 64 bits for dw_val_class_const_double. - Which setups use 32bit (or lower?) HOST_BITS_PER_WIDE_INT? i686 seems to require 64BIT HOST_WIDE_INTs too these days. I would like to test a bit on a setup that uses HOST_BITS_PER_WIDE_INT < 64 because currently I believe the use of add_AT_double is slightly wrong in dwarf2out. It looks like a DWARF consumer can no longer rely on simply zero-extending DW_FORM_data[1248] values if add_AT_double is used. And add_AT_double is currently used for two slightly different things. To output constant class values (such as bounds) that don't fit a HOST_WIDE_INT and to output large (block class) values for DW_AT_const_value. But these are not always similar (constants class values cannot be represented by DW_FORM_block for example). So it would be good to at least have a add_AT_double_unsigned and add_AT_double_int that can be used just like add_AT_unsigned and add_AT_int. That seems to also require some additions to be able to output DW_FORM_sdata for constants larger than HOST_WIDE_INT in dwarf2asm. Any thoughts on this? Thanks, Mark --- gcc/dwarf2out.c | 32 ++++++++++++++++++++------------ 1 files changed, 20 insertions(+), 12 deletions(-) diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 2b584a5..9f8b3b0 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -16198,21 +16198,29 @@ add_bound_info (dw_die_ref subrange_die, enum dwarf_attribute bound_attr, tree b && tree_to_shwi (bound) == dflt) ; - /* 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. */ - else if (prec < HOST_BITS_PER_WIDE_INT) + /* If HOST_WIDE_INT is big enough then represent the bound as + a constant value. Note that we need to make sure the type + is signed or unsigned. We cannot just add an unsigned + constant if the value itself is positive. Some DWARF + consumers will lookup the bounds type and then sign extend + any unsigned values found for signed types. This is only + for DW_AT_lower_bound, normally unsigned values + (DW_FORM_data[1248]) are assumed to not need + sign-extension. */ + else if (prec <= HOST_BITS_PER_WIDE_INT + || TREE_INT_CST_HIGH (bound) == 0) { - unsigned HOST_WIDE_INT mask - = ((unsigned HOST_WIDE_INT) 1 << prec) - 1; - add_AT_unsigned (subrange_die, bound_attr, - TREE_INT_CST_LOW (bound) & mask); + if (TYPE_UNSIGNED (TREE_TYPE (bound))) + add_AT_unsigned (subrange_die, bound_attr, + TREE_INT_CST_LOW (bound)); + else + add_AT_int (subrange_die, bound_attr, TREE_INT_CST_LOW (bound)); } - else if (prec == HOST_BITS_PER_WIDE_INT - || TREE_INT_CST_HIGH (bound) == 0) - add_AT_unsigned (subrange_die, bound_attr, - TREE_INT_CST_LOW (bound)); else + /* 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. */ add_AT_double (subrange_die, bound_attr, TREE_INT_CST_HIGH (bound), TREE_INT_CST_LOW (bound)); }