From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 98262385802B for ; Sun, 14 Feb 2021 19:19:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 98262385802B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-398-soMSwdZ_O3-9up1_bAnooA-1; Sun, 14 Feb 2021 14:19:50 -0500 X-MC-Unique: soMSwdZ_O3-9up1_bAnooA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DA4C18030B7; Sun, 14 Feb 2021 19:19:48 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-197.ams2.redhat.com [10.36.112.197]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6CD0C1F0; Sun, 14 Feb 2021 19:19:48 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 11EJJjSj1638260 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sun, 14 Feb 2021 20:19:45 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 11EJJhDM1638259; Sun, 14 Feb 2021 20:19:43 +0100 Date: Sun, 14 Feb 2021 20:19:43 +0100 From: Jakub Jelinek To: Mark Wielaard Cc: Tom de Vries , dwz@sourceware.org Subject: Re: [PATCH] Handle DW_FORM_implicit_const for DW_AT_decl_line Message-ID: <20210214191943.GP4020736@tucnak> Reply-To: Jakub Jelinek References: <20210214085202.GA16780@delia> <655872bb0320602ddab5663078db3c65c07464c0.camel@klomp.org> MIME-Version: 1.0 In-Reply-To: <655872bb0320602ddab5663078db3c65c07464c0.camel@klomp.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, 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: Sun, 14 Feb 2021 19:19:54 -0000 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. Jakub