public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Torsten Polle <Torsten.Polle@gmx.de>
Cc: Sasha Da Rocha Pinheiro <darochapinhe@wisc.edu>,
		"elfutils-devel@sourceware.org"	 <elfutils-devel@sourceware.org>
Subject: Re: Read .debug_line without .debug_info
Date: Tue, 27 Mar 2018 09:09:00 -0000	[thread overview]
Message-ID: <1522141768.15770.53.camel@klomp.org> (raw)
In-Reply-To: <E154ECF3-D5D4-4834-B0FE-DC5CEED4DFB0@gmx.de>

On Mon, 2018-03-26 at 21:24 +0200, Torsten Polle wrote:
> > > > Am 26.03.2018 um 21:12 schrieb Mark Wielaard <mark@klomp.org>:
> > 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?
> > 
> > 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.
> 
> you could take this information from the include directories:
> 
> "11. include_directories (sequence of path names)
> 
> Entries in this sequence describe each path that was searched for included source files in this compilation. (The paths include those directories specified explicitly by the user for the compiler to search and those the compiler searches without explicit direction.) Each path entry is either a full path name or is relative to the current directory of the compilation.
> 
> The last entry is followed by a single null byte.
> 
> The line number program assigns numbers to each of the file entries in order, beginning with 1. The current directory of the compilation is understood 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

      reply	other threads:[~2018-03-27  9:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 16:41 Sasha Da Rocha Pinheiro
2018-03-26 19:12 ` Mark Wielaard
2018-03-26 19:25   ` Torsten Polle
2018-03-27  9:09     ` Mark Wielaard [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1522141768.15770.53.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=Torsten.Polle@gmx.de \
    --cc=darochapinhe@wisc.edu \
    --cc=elfutils-devel@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).