[Bug libdw/22452] Extend ebl_reloc_ hooks with relocations against load address for use in libdwfl/relocate.c
https://sourceware.org/bugzilla/show_bug.cgi?id=22452 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Mark Wielaard --- (In reply to Mark Wielaard from comment #15) > Did you manage to get a kernel build change upstream? > It would be nice to point people at it in this bug in case they hit the same > issue. So they know how to rebuild their kernel. commit bc3703f21cec8a2ac6a64f6fb3686fbcb1ba1513 Author: Hendrik Brueckner Date: Mon Nov 20 11:41:07 2017 +0100 s390/kernel: emit CFI data in .debug_frame and discard .eh_frame sections Using perf probe and libdw on kernel modules failed to find CFI data for symbols. The CFI data is stored in the .eh_frame section. The elfutils libdw is not able to extract the CFI data correctly, because the .eh_frame section requires "non-simple" relocations for kernel modules. The suggestion is to avoid these "non-simple" relocations by emitting the CFI data in the .debug_frame section. Let gcc emit respective directives by specifying the -fno-asynchronous-unwind-tables option. Using the .debug_frame section for CFI data, the .eh_frame section becomes unused and, thus, discard it for kernel and modules builds The vDSO requires the .eh_frame section and, hence, emit the CFI data in both, the .eh_frame and .debug_frame sections. See also discussion on elfutils/libdw bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=22452 Suggested-by: Mark Wielaard Signed-off-by: Hendrik Brueckner Reviewed-by: Heiko Carstens Signed-off-by: Martin Schwidefsky > I have retitled this bug and will keep it open in case someone has > time for implementing the ebl hooks for relative load address relocations. I think the above kernel fix is a better. And there really is not much benefit to have relative load address relocations for .eh_frame except for these ET_REL .ko files. Also, nobody seems to have time. So lets close this for now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/22892] heap-buffer-overflow in check_group function (src/elflint.c)
https://sourceware.org/bugzilla/show_bug.cgi?id=22892 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit 22e282071021fc5ada2b9294bfa7e25fbd62a9d6 Author: Mark Wielaard Date: Mon Feb 26 22:53:10 2018 +0100 elflint: Make sure we can read a whole element when iterating over group. Change the for loop so that we can always read a full element. https://sourceware.org/bugzilla/show_bug.cgi?id=22892 Signed-off-by: Mark Wielaard -- You are receiving this mail because: You are on the CC list for the bug.
[Bug spam/22801] Contact Us 1800 201 2898 Amazon Echo Tech Support Number
https://sourceware.org/bugzilla/show_bug.cgi?id=22801 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|elfutils-devel at sourceware dot o | |rg | Component|backends|spam Resolution|--- |INVALID Assignee|unassigned at sourceware dot org |nobody at sourceware dot org Product|elfutils|web --- Comment #1 from Mark Wielaard --- spam -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] libdwfl: Use realpath (name, NULL) instead of canonicalize_file_name (name).
Some systems apparently don't provide canonicalize_file_name. Since
canonicalize_file_name (path) is defined as realpath(path, NULL) just
use realpath everywhere.
https://sourceware.org/bugzilla/show_bug.cgi?id=21009
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog| 6 ++
libdwfl/dwfl_build_id_find_elf.c | 2 +-
libdwfl/find-debuginfo.c | 2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index b2a7497..1515c41 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,9 @@
+2018-03-05 Mark Wielaard
+
+ * dwfl_build_id_find_elf.c (__libdwfl_open_by_build_id): Use
+ realpath (name, NULL) instead of canonicalize_file_name (name).
+ * find-debuginfo.c (dwfl_standard_find_debuginfo): Likewise.
+
2018-01-29 Mark Wielaard
* cu.c (cudie_offset): Use __libdw_first_die_off_from_cu instead of
diff --git a/libdwfl/dwfl_build_id_find_elf.c b/libdwfl/dwfl_build_id_find_elf.c
index ee0c164..cc6c3f6 100644
--- a/libdwfl/dwfl_build_id_find_elf.c
+++ b/libdwfl/dwfl_build_id_find_elf.c
@@ -99,7 +99,7 @@ __libdwfl_open_by_build_id (Dwfl_Module *mod, bool debug,
char **file_name,
{
if (*file_name != NULL)
free (*file_name);
- *file_name = canonicalize_file_name (name);
+ *file_name = realpath (name, NULL);
if (*file_name == NULL)
{
*file_name = name;
diff --git a/libdwfl/find-debuginfo.c b/libdwfl/find-debuginfo.c
index 6d5a42a..9267788 100644
--- a/libdwfl/find-debuginfo.c
+++ b/libdwfl/find-debuginfo.c
@@ -389,7 +389,7 @@ dwfl_standard_find_debuginfo (Dwfl_Module *mod,
/* If FILE_NAME is a symlink, the debug file might be associated
with the symlink target name instead. */
- char *canon = canonicalize_file_name (file_name);
+ char *canon = realpath (file_name, NULL);
if (canon != NULL && strcmp (file_name, canon))
fd = find_debuginfo_in_path (mod, canon,
debuglink_file, debuglink_crc,
--
1.8.3.1
[Bug general/21009] Incompatible with MUSL libc: canonicalize_file_name
https://sourceware.org/bugzilla/show_bug.cgi?id=21009 --- Comment #2 from Mark Wielaard --- (In reply to Mark Wielaard from comment #1) > I think we can assume everybody uses glibc or a modern alternative that > already implements the resolved_path == NULL feature. So I would simply > change the two callers of canonicalize_file_name (name) to realpath (name, > NULL). https://sourceware.org/ml/elfutils-devel/2018-q1/msg00066.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/22865] [objdump] Arbitrary memory write in default_syscall_abi of eblopenbackend.c.
https://sourceware.org/bugzilla/show_bug.cgi?id=22865 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Mark Wielaard --- Without a way to replicate this issue it is impossible to resolve or know what the real issue is. Please reopen if you are still able to reproduce it. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] readelf: Add some support for locviews.
On Thu, 2018-03-01 at 14:55 +0100, Mark Wielaard wrote: > This adds minimal support for locviews as output by GCC8. > It changes readelf to keep track of loclistptrs from DW_AT_GNU_locviews > and prints the locview pairs for those. Since there is no terminator > we have to keep track of where the next loclist entry starts. > The --debug-dump=loc output looks as follows: > > CU [ 714] base: +0x3020 > [b4] view pair 1, 2 > [b6] range 4, 7f > +0x3024 .. > +0x309e > [ 0] reg5 > [d9] view pair 3, 1 > view pair 1, 2 > [dd] range 4, 4c > +0x3024 .. > +0x306b > [ 0] reg5 > range 4c, 7f > +0x306c .. > +0x309e > [ 0] reg2 > > Note that in the above output the view pairs correspond to the ranges > immediately following in the loc list. This is how GCC8 currently > outputs the locview pairs and ranges, but this is not guaranteed and > you'll need to look at the location and GNU_locviews attributes of the > DIE to know which really match up together. We might want to adjust the > output to make this more clear. > > This does not yet add an locview accessor to libdw. It just recognizes > the DW_AT_GNU_locviews attribute as a loclistptr when encoded as a > sec_offset form. Pushed to master.
