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 541D43858422 for ; Sat, 24 Feb 2024 14:00:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 541D43858422 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 541D43858422 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708783207; cv=none; b=jup62X41IsomqZuve3i8LdQ/jsHQvEhqz8esHO3E2hFhOX7w4kDhvd/Pi6JfSwzxAs+3fGQyyuVTkRwwGW5n20rk72d2lM5/3USlf+HxW0PvPiTJHRWQ3mHzM3tezBVCi9xvTcwhMxKQ4pkhz1oF+izC14H0hXfl52wovxwYbe8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708783207; c=relaxed/simple; bh=doDKWEe3Yyn+CjgTfMb6G83dLlwYM9M12YLWFabllj4=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=dTN6ZcfQ7hgWWM31fKVNy5HXktpcC+uI8bTlSJuC90WlHF9XZ5R93082oKlu5Xtc6Z2P8c7ad3wvepu06AOiXv0Jpn37Jnt0R6upCB4Zk4Krrs8al/zBefQDly/XpVOI1VJ/gT0Dja5TytcK+EbtYWJMk84PGTEzAJL4Wg/CXqQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 5F4B93000400; Sat, 24 Feb 2024 15:00:04 +0100 (CET) Date: Sat, 24 Feb 2024 15:00:04 +0100 From: Mark Wielaard To: Omar Sandoval Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH v2 3/4] libdw: Apply DWARF package file section offsets where appropriate Message-ID: <20240224140004.GB1353@gnu.wildebeest.org> References: <824d09edb009fd7cf3befcd871742f8089793c5e.1701854319.git.osandov@fb.com> <2f2aedc63120761bd82663442cef6a5330c80cd6.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Thu, Feb 22, 2024 at 05:03:44PM -0800, Omar Sandoval wrote: > On Thu, Feb 22, 2024 at 04:53:19PM -0800, Omar Sandoval wrote: > > On Fri, Feb 16, 2024 at 04:00:47PM +0100, Mark Wielaard wrote: > > > Don't we also need to handle DW_SECT_LINE in dwarf_getsrclines and > > > dwarf_next_lines when looking for DW_AT_stmt_list? > > > > .debug_line is the odd one out in split DWARF: the skeleton file > > contains the full .debug_line, and the DWO or DWP files have a skeleton > > .debug_line.dwo that only contains the directory and file name tables > > (for DW_AT_file and macro info to reference). dwarf_getsrclines and co. > > read from the skeleton file, not the DWP file, meaning they shouldn't > > use DW_SECT_LINE. > > Ah, I guess you can call dwarf_getsrclines/dwarf_next_lines on the dwp > file itself, where DW_SECT_LINE may be applicable. I need to think about > that some more... So reading the DWARF5 spec, it says a split DWARF CU/TU DIE may have a DW_AT_stmt_list, which are interpreted as relative to the base offset for .debug_line.dwo. And these tables contain only the directory and filename lists needed to interpret DW_AT_decl_file attributes in the debugging information entries. Actual line number tables remain in the .debug_line section, and remain in the relocatable object (.o) files. So I think the intention is that the main .debug_line (skeleton) section does contain the actual line number table, but only those file/dir table entries that are referenced from that. Not any that are only referenced from the DW_AT_decl_file attributes (which should only appear in the split DWARF DIEs). Maybe in practice these overlap completely, so there is no savings and they are in practice identical. But I don't see anything in the spec that implies you should interpret a lineptr in the .debug_info.dwo as relative to the .debug_line section in the skeleton. Cheers, Mark