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 F1830385802D for ; Thu, 18 Feb 2021 14:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F1830385802D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.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 866303032F94; Thu, 18 Feb 2021 15:45:08 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 567B0400100E; Thu, 18 Feb 2021 15:45:08 +0100 (CET) Message-ID: <15566cfaba36c121561e2ca8a0e3f1ffa2b042ed.camel@klomp.org> Subject: Re: Plan to contribute for supporting split dwarf (-gsplit-dwarf) in dwz From: Mark Wielaard To: "E, Nagajyothi" , "dwz@sourceware.org" Cc: "George, Jini Susan" , "Achra, Nitika" , "Sharma, Alok Kumar" Date: Thu, 18 Feb 2021 15:45:08 +0100 In-Reply-To: References: <20210215185417.GC3149@wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, 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, 18 Feb 2021 14:45:15 -0000 Hi Nagajyothi, On Wed, 2021-02-17 at 05:53 +0000, E, Nagajyothi via Dwz wrote: > I am working on adding support for the dwarf5 .debug_str_offsets, > .debug_addr sections and the related forms DW_FORM_strx[1234], DW_FORM_ad= drx[1234]. > Please let me know if anyone has already started work on these. Thanks, I don't believe anybody is working on this right now. There is already a bug for .debug_addr/DW_FORM_addrx[1234] support: https://sourceware.org/bugzilla/show_bug.cgi?id=3D27375 I think this shouldn't be too hard. Any DIE that references an address cannot be moved to an alt file, so simply mark it with die_no_multifile. We do try to optimize DW_AT_low/high_pc attribute pairs, so double check that doesn't interfere with DW_FORM_addrx[1234] processing. Also note that there are two new location operations DW_OP_addrx and DW_OP_constx that can reference the .debug_addr section index. As a followup you could try optimizing things, but then you need to keep track of all the addresses used and see if there are duplicates that could be turned into a (smaller) DW_FORM_addrx[1234] index. But I would keep that separate from the initial implementation. For .debug_str_offset/DW_FORM_strx[1234] I opened a new bug. https://sourceware.org/bugzilla/show_bug.cgi?id=3D27434 This is a little trickier than DW_FORM_addrx[1234] since such DIEs using DW_FORM_strx may be moved to a multifile. You also probably want to make them equal to DW_FORM_strp entries pointing (indirectly) to the same string. You might want to add a note to the the bugs that you are working on them. Thanks, Mark