From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 242BC385802B for ; Sun, 14 Feb 2021 19:10:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 242BC385802B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 1EFE03032F8D; Sun, 14 Feb 2021 20:10:49 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id C7B5540007A5; Sun, 14 Feb 2021 20:10:49 +0100 (CET) Message-ID: <655872bb0320602ddab5663078db3c65c07464c0.camel@klomp.org> Subject: Re: [PATCH] Handle DW_FORM_implicit_const for DW_AT_decl_line From: Mark Wielaard To: Tom de Vries , dwz@sourceware.org, jakub@redhat.com Date: Sun, 14 Feb 2021 20:10:49 +0100 In-Reply-To: <20210214085202.GA16780@delia> References: <20210214085202.GA16780@delia> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2021 19:10:52 -0000 Hi Tom, On Sun, 2021-02-14 at 09:52 +0100, Tom de Vries wrote: > due to the DW_AT_decl_line attribute having different forms, > DW_FORM_data1 and > DW_FORM_implicit_const. >=20 > Fix this in checksum_die and die_eq_1 by adding dedicated handling for > DW_AT_decl_line, similar to how that's done for DW_AT_decl_file. >=20 > Any comments? Yes, this makes sense. Like you said, we do something like this already for decl/call_file. I think technically the die_eq_1 part could be put under the same switch case. But maybe you find it clearer to do it separately to mirror the checksum_die part? Together with your DW_LANG_C_plus_plus_{03,11,14} patch it fixes the -- odr testsuite failures I was seeing. As a follow up this might actually make sense for more attributes. Where we know the attribute value is interpreted as an signed or unsigned value (so we know what data[124] represents). This is actually slightly tricky, because it isn't always immediately clear which attribute values DWARF intends to be signed/unsigned, and it might even differ per language (or whether or not an attribute is associated with a [referenced] signed or unsigned type). But the following seem to be always be unsigned values that might qualify because they have unsigned constants assigned: DW_AT_encoding DW_AT_decimal_sign DW_AT_endianity DW_AT_accessibility DW_AT_visibility DW_AT_virtuality DW_AT_language DW_AT_address_class DW_AT_identifier_case DW_AT_calling_convention DW_AT_inline DW_AT_ordering DW_AT_discr_list DW_AT_defaulted And the following qualify because they describe sizes, or counts, when constant class: DW_AT_byte_size DW_AT_bit_size DW_AT_count DW_AT_digit_count DW_AT_rank DW_AT_string_length_bit_size DW_AT_string_length_byte_size DW_AT_alignment As are these when constant class, indicating positive offsets DW_AT_high_pc DW_AT_start_scope DW_AT_data_member_location DW_AT_data_bit_offset Cheers, Mark