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 91D343857800 for ; Mon, 14 Sep 2020 10:24:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 91D343857800 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@tarox.wildebeest.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 E9AFC300BC89 for ; Mon, 14 Sep 2020 12:24:11 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id C70004000CBE; Mon, 14 Sep 2020 12:24:11 +0200 (CEST) From: Mark Wielaard To: dwz@sourceware.org Subject: DWARF5 support for dwz Date: Mon, 14 Sep 2020 12:23:51 +0200 Message-Id: <20200914102355.8137-1-mark@klomp.org> X-Mailer: git-send-email 2.18.4 X-Spam-Status: No, score=-32.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, KHOP_HELO_FCRDNS, SPF_HELO_NONE, SPF_NONE, 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: Mon, 14 Sep 2020 10:24:15 -0000 Hi, At the virtual GNU tools cauldron we had a little session about making DWARF5 the default for GCC. GCC, binutils and gdb seem ready now, so next up is DWZ. https://gcc.gnu.org/wiki/LPC2020NotesDWARF 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 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. There are a couple of forms that GCC only emits when generating split-DWARF that I don't intend to implement righ now, DW_FORM_strx, DW_FORM_addrx, DW_FORM_loclistx and DW_FORM_rnglistx. 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?) After the new FORMs patches are needed to read the new .debug_loclists and .debug_rnglists sections. Then parse the .debug_line version 5 variant (which gcc currently doesn't emit yet, but I have patches to make it do so through binutils gas). Finally we need to write out all the new data formats and possibly optimize for the new forms. Cheers, Mark