Re: Read .debug_line without .debug_info
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 +, 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
Re: [PATCH] readelf: Report error when decl_file or call_file attribute is invalid.
On Tue, 2018-03-20 at 13:33 +0100, Mark Wielaard wrote:
> Report an error for why the DW_AT_decl_file or DW_AT_call_file cannot
> be resolved to a file name. This is likely invalid DWARF, a missing
> DW_AT_stmt_list attribute on the CU or a missing .debug_line section.
I pushed this to master with one tiny change, at the end of the error
checking this is added:
diff --git a/src/readelf.c b/src/readelf.c
index 72b5469..fc5aab7 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -6780,6 +6780,8 @@ attr_callback (Dwarf_Attribute *attrp, void *arg)
else
error (0, 0, gettext ("couldn't get DWARF CU: %s"),
dwarf_errmsg (-1));
+ if (valuestr == NULL)
+ valuestr = "???";
}
break;
That way you don't just get a stderr message, but can also see in the
DIE tree output that the actual file name is missing. So with that the
output for a bogus DW_AT_decl_file would look like:
[1b]typedef abbrev: 2
name (GNU_str_index) "size_t"
src/readelf: no srcfiles for CU [b]
decl_file(data1) ??? (5)
decl_line(data1) 216
type (ref4) [24]
Cheers,
Mark
Re: [PATCH] readelf: Report error when decl_file or call_file attribute is invalid.
On Tue, 2018-03-27 at 15:42 +0200, Mark Wielaard wrote:
> On Tue, 2018-03-20 at 13:33 +0100, Mark Wielaard wrote:
> > Report an error for why the DW_AT_decl_file or DW_AT_call_file
> > cannot
> > be resolved to a file name. This is likely invalid DWARF, a missing
> > DW_AT_stmt_list attribute on the CU or a missing .debug_line
> > section.
>
> I pushed this to master
And the buildbot flagged an issue on debian-i686:
https://builder.wildebeest.org/buildbot/#/builders/4/builds/110
readelf.c: In function ‘attr_callback’:
readelf.c:6261:27: error: format ‘%zx’ expects argument of type ‘size_t’, but
argument 4 has type ‘Dwarf_Off {aka long long unsigned int}’ [-Werror=format=]
error (0, 0, gettext ("no srcfiles for CU [%zx]"),
^
Oops. Sorry about that. Fixed as attached.
From f0d7b3e14779cdf5facede98edc924ef1266b785 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Tue, 27 Mar 2018 16:22:16 +0200
Subject: [PATCH] readelf: Print dwarf_dieoffset as %PRIx64, not %zx.
On 32bit architectures size_t is not 64bit...
Signed-off-by: Mark Wielaard
---
src/ChangeLog | 5 +
src/readelf.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/ChangeLog b/src/ChangeLog
index f2f99ed..1ad6b3d 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2018-03-27 Mark Wielaard
+
+ * readelf.c (attr_callback): Print dwarf_dieoffset as %PRIx64,
+ not %zx.
+
2018-03-20 Mark Wielaard
* readelf.c (attr_callback): Report error when DW_AT_decl_file or
diff --git a/src/readelf.c b/src/readelf.c
index 8a96881..4e35b61 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -6258,7 +6258,7 @@ attr_callback (Dwarf_Attribute *attrp, void *arg)
num, dwarf_errmsg (-1));
}
else
- error (0, 0, gettext ("no srcfiles for CU [%zx]"),
+ error (0, 0, gettext ("no srcfiles for CU [%" PRIx64 "]"),
dwarf_dieoffset (&cudie));
}
else
--
1.8.3.1
