From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id CE9BC3858C74 for ; Tue, 3 Oct 2023 21:49:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE9BC3858C74 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 01F1730067D1; Tue, 3 Oct 2023 23:49:32 +0200 (CEST) Date: Tue, 3 Oct 2023 23:49:31 +0200 From: Mark Wielaard To: Omar Sandoval Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH 06/14] libdw: Handle split DWARF in dwarf_macro_getsrcfiles Message-ID: <20231003214931.GH32765@gnu.wildebeest.org> References: <4d46a2bb0eba8e3aff5a33c045cd5a75342d596b.1695837512.git.osandov@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d46a2bb0eba8e3aff5a33c045cd5a75342d596b.1695837512.git.osandov@fb.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3028.6 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Omar, On Wed, Sep 27, 2023 at 11:20:55AM -0700, Omar Sandoval wrote: > Macro information references file names from the line number information > table, which is tricky in split DWARF for a couple of reasons. > > First, the line number information for a macro unit comes from the > .debug_line.dwo section in the split file, not the .debug_line section > in the skeleton file. This was not specified in the GNU DebugFission > design document [1] or the DWARF 5 standard, but it is how GCC and Clang > behave in practice and was clarified in DWARF standard issue > 200602.1 [2] for the upcoming DWARF 6 standard. > > dwarf_macro_getsrcfiles uses the line number information from whichever > Dwarf handle it was passed. This is error-prone, since the most natural > thing to do is to pass the skeleton Dwarf handle. Fix this by storing > the appropriate Dwarf handle in Dwarf_Macro_Op_Table and using that one. Too bad we cannot fix the function signature because that would be an API break. But this makes sense (thanks again for the references). > Second, for .debug_macinfo.dwo in GNU DebugFission (generated by gcc > -gdwarf-4 -gstrict-dwarf -gsplit-dwarf), the offset into .debug_line.dwo > is implicitly 0. Again, this isn't in any specification, but it's how > GCC behaves in practice (Clang never generates macro information for > DWARF 4 split DWARF). Make get_macinfo_table default to 0 for split > DWARF when it can't find DW_AT_stmt_list. Makes sense, it cannot really be any other offset than zero. Applied, Mark