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 9FE7E3857C52 for ; Thu, 24 Sep 2020 16:26:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9FE7E3857C52 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 320CA3000F11 for ; Thu, 24 Sep 2020 18:26:05 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 17F92470867C; Thu, 24 Sep 2020 18:26:05 +0200 (CEST) From: Mark Wielaard To: dwz@sourceware.org Subject: Read and write DWARF5 units and forms Date: Thu, 24 Sep 2020 18:25:53 +0200 Message-Id: <20200924162557.15870-1-mark@klomp.org> X-Mailer: git-send-email 2.18.4 X-Spam-Status: No, score=-33.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, 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: Thu, 24 Sep 2020 16:26:09 -0000 Hi, The following patches implement reading and writing of DWARF5 units and forms (excluding the split-dwarf DW_FORM_strx, DW_FORM_addrx, DW_FORM_loclistx and DW_FORM_rnglistx) This makes dwz able to process and write out DWARF5 as generated by GCC for various files (as long as they don't contain loclists or DWARF5 debug line tables). [PATCH 1/4] Calculate size and write correct DWARF5 header [PATCH 2/4] Handle DW_FORM_data16. [PATCH 3/4] Handle DW_FORM_line_strp by not moving DIE. [PATCH 4/4] Handle DW_FORM_implicit_const [experiment]. I believe the first two patches are good to go. A DWARF5 unit header is 1 byte larger and has a different order for some of the fields. DW_FORM_data16 is simple since it is just 16 bytes of data that doesn't need to be treated specially for any attribute. For now DW_FORM_line_strp is also fairly simple. But that is mainly because I made it so that DIEs cannot be moved to a multifile. There is no .debug_line_str section in a supplemental file. I like to push this change for now and then revisit how to handle line_strp when adding support for DWARF5 .debug_line tables. It makes sense to merge all dir and line table strings into the the supplemental .debug_str table (so both the main file and multifile can refer to them using DW_FORM_strp or DW_FORM_GNU_strp_alt/DW_FORM_strp_sup). The last patch is a work in progress. DW_FORM_implicit_const keeps the actual data value in the abbrev. This makes things tricky because we have to decide where to keep (a reference to) the value and when to update the value if necessary. In particular DW_FORM_implicit_const might be used with a line table index for the DW_AT_decl_file or DW_AT_call_file attributes which might need updating in multifile mode. The patch commit message contains some questions how to handle this better than is done now. In particular I think the value updates are done at the wrong point because I see various odr failures which seem to indicate some DIEs aren't correctly detected as being similar. I am also not sure things work correctly for --devel-ignore-locus. Suggestions on how to handle this better would be very welcome. I want to first work on handling the new .debug_loclists, .debug_rnglists sections and parsing/writing of version 5 .debugline. Then come back to properly handling DW_FORM_implicit_const. Note that to make the testsuite work (there are still some failures when building with make check CC="gcc -gdwarf-5" CXX="g++ -gdwarf-5") you need binutils 2.35.1 (released this week) plus at least this patch: https://sourceware.org/pipermail/binutils/2020-September/113425.html Cheers, Mark