From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42453 invoked by alias); 27 Mar 2018 09:09:37 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 42437 invoked by uid 89); 27 Mar 2018 09:09:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Mar 2018 09:09:31 +0000 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 1B86730146B2; Tue, 27 Mar 2018 11:09:29 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 0388B40AF630; Tue, 27 Mar 2018 11:09:28 +0200 (CEST) Message-ID: <1522141768.15770.53.camel@klomp.org> Subject: Re: Read .debug_line without .debug_info From: Mark Wielaard To: Torsten Polle Cc: Sasha Da Rocha Pinheiro , "elfutils-devel@sourceware.org" Date: Tue, 27 Mar 2018 09:09:00 -0000 In-Reply-To: References: <20180326191201.GC9061@wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00112.txt.bz2 On Mon, 2018-03-26 at 21:24 +0200, Torsten Polle wrote: > > > > Am 26.03.2018 um 21:12 schrieb Mark Wielaard : > > On Mon, Mar 26, 2018 at 04:41:06PM +0000, Sasha Da Rocha Pinheiro wrote: > > > is it possible to read contents of .debug_line section without the > > > presence of a .debug_info section? > >=20 > > No, because .debug_line sections need some information from the CU > > which comes from the .debug_info. In particular the directory table > > starts with the compilation directory which can only be gotten from > > the CU (DW_AT_comp_dir). The files in the file list (which don't have > > an explicit dir associated) are all given relative to that comp dir. >=20 > you could take this information from the include directories: >=20 > "11. include_directories (sequence of path names) >=20 > Entries in this sequence describe each path that was searched for include= d source files in this compilation. (The paths include those directories sp= ecified explicitly by the user for the compiler to search and those the com= piler searches without explicit direction.) Each path entry is either a ful= l path name or is relative to the current directory of the compilation. >=20 > The last entry is followed by a single null byte. >=20 > The line number program assigns numbers to each of the file entries in or= der, beginning with 1. The current directory of the compilation is understo= od to be the zeroth entry and is not explicitly represented." Yes, you are right, if the files don't refer to the current directory (index zero). But normally most files will be relative to the current directory, which (at least in DWARF < 5) is not explicitly represented in the directory table, only implicitly as the CU comp_dir attribute. Also if you are interested in the code ranges that are covered by the line table, you have to parse the whole table up front without an associated debuginfo CU DIE. This might or might not be an issue, but it is if you have multiple line tables and you quickly need to find the one that covers a specific address. So, yes, the line tables might be usable without the .debug_info present, but it isn't as convenient. Cheers, Mark