From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 9422E3857C57 for ; Mon, 14 Sep 2020 10:48:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9422E3857C57 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-260-Lw4LK2CZML-li8rW8D4e0Q-1; Mon, 14 Sep 2020 06:48:09 -0400 X-MC-Unique: Lw4LK2CZML-li8rW8D4e0Q-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 46EF81017DD2; Mon, 14 Sep 2020 10:48:08 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-252.ams2.redhat.com [10.36.113.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E744E7512A; Mon, 14 Sep 2020 10:48:07 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 08EAm4R8031698; Mon, 14 Sep 2020 12:48:05 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 08EAm4FW031697; Mon, 14 Sep 2020 12:48:04 +0200 Date: Mon, 14 Sep 2020 12:48:04 +0200 From: Jakub Jelinek To: Mark Wielaard Cc: dwz@sourceware.org Subject: Re: DWARF5 support for dwz Message-ID: <20200914104804.GB21814@tucnak> Reply-To: Jakub Jelinek References: <20200914102355.8137-1-mark@klomp.org> MIME-Version: 1.0 In-Reply-To: <20200914102355.8137-1-mark@klomp.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0.003 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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, 14 Sep 2020 10:48:13 -0000 On Mon, Sep 14, 2020 at 12:23:51PM +0200, Mark Wielaard wrote: > Since nobody volunteered to add DWARF5 support I started > on some simple patches. The following 4 patches handle the easy parts. > Recognize some new DWARF5 .debug sections. Handle DWARF5 headers for Thanks for working on this. > compile and partial units. Handle new DWARF5 attributes. And handle > some new DWARF5 operations as their GNU extension. > > Next up is the harder part, parsing the new FORMs. DW_FORM_data16 > should be easy. DW_FORM_line_strp is easy in principle, but might need > some thought to see how/if DIEs that reference the new .debug_line_str > can be moved (.debug_line_str itself cannot be moved to the supplemental > file so the string itself, and possibly .debug_line, should be rewritten > to point to the shared supplemental .debug_str section). The hard part > is DW_FORM_implicit_const which has its value in the abbrev, so just > having form plus .debug_info ptr isn't enough to read it. I think I have > a solution to that issue, but have to check how it interacts with the > hashing and writing out the new from. For DW_FORM_implicit_const, handling it when reading should be similar to how DW_FORM_flag_present is handled already. The harded will be the optimization part, figure out when it is worth to split an abbreviation to two or more in order to introduce more DW_FORM_implicit_const forms to make it an overall gain. On the negative side that means growth in .debug_abbrev section and some growth in the uleb128s referencing the new abbreviations, so it would need to do it smartly and only when beneficial. > Also there are standardized forms for GNU_ref_alt and GNU_strp_alt > (DW_FORM_ref_sup4, DW_FORM_ref_sup8 and DW_FORM_strp_sup) which I don't > want to use for now since they would require updates to consumers > (just like switching from .gnu_debugaltlink to .debug_sup). So I hold > those to the end (maybe we will introduce a new --dwarf5 flag for that?) Yeah, some switch at least for the transition period would be worthwhile. Because the consumers can't be really adjusted to handle it until dwz is able to emit that, and dwz can't switch to doing it by default until at least the majority of consumers are adjusted. My memory is fuzzy, don't we need some adjustments to the expected gain computations with dwarf5 because the section headers will have now different sizes? Jakub