From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id A2AD0385E00E for ; Mon, 15 Feb 2021 12:54:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A2AD0385E00E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BA3BDAC32; Mon, 15 Feb 2021 12:54:20 +0000 (UTC) Subject: Re: [PATCH] Handle DW_FORM_implicit_const for DW_AT_decl_line From: Tom de Vries To: Jakub Jelinek , Mark Wielaard Cc: dwz@sourceware.org References: <20210214085202.GA16780@delia> <655872bb0320602ddab5663078db3c65c07464c0.camel@klomp.org> <20210214191943.GP4020736@tucnak> Message-ID: <83a474d1-cf04-2682-169b-3d75a73902d4@suse.de> Date: Mon, 15 Feb 2021 13:54:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Mon, 15 Feb 2021 12:54:22 -0000 On 2/14/21 10:27 PM, Tom de Vries wrote: > On 2/14/21 8:19 PM, Jakub Jelinek wrote: >> On Sun, Feb 14, 2021 at 08:10:49PM +0100, Mark Wielaard wrote: >>> 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? >> >> Yeah, I'm wondering if we just shouldn't hash and compare all constant class >> forms with the same value the same (ok, except DW_FORM_data16 which is too >> large). For DW_FORM_data{1,2,4,8} we don't know if it is signed or >> unsigned, so perhaps just treat values with the msb clear that way? >> Or sure, if we can put in a list of attributes that always have unsigned >> or always have signed constants, we can even improve that. > > Make sense to me. Filed as PR27421 - Improve DW_FORM_implicit_const handling in checksum_die/die_eq_1 ( https://sourceware.org/bugzilla/show_bug.cgi?id=27421 ). Thanks, - Tom