[Bug libdw/26177] eu-unstrip -n -k fails on kernels 4.14-4.19
https://sourceware.org/bugzilla/show_bug.cgi?id=26177
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-06-27
CC||mark at klomp dot org
Ever confirmed|0 |1
--- Comment #1 from Mark Wielaard ---
Thanks for the analysis. These __entry_SYSCALL_64_trampoline are really odd.
Your suggested fix works, but I would like to not depend on the specific symbol
name if at all possible.
Ad you say the problem is that they come after the last kernel address, but
before the module addresses. And they are smaller than the start address we
found.
The following check that the address read is larger than the start address we
found seems to fix it for me. Does it work for you?
diff --git a/libdwfl/linux-kernel-modules.c b/libdwfl/linux-kernel-modules.c
index 84a05f28..5e6cf275 100644
--- a/libdwfl/linux-kernel-modules.c
+++ b/libdwfl/linux-kernel-modules.c
@@ -538,10 +538,14 @@ intuit_kernel_bounds (Dwarf_Addr *start, Dwarf_Addr *end,
Dwarf_Addr *notes)
if (result == 0)
{
+ Dwarf_Addr addr;
*end = *start;
- while (read_address (&state, end))
- if (*notes == 0 && !strcmp (state.p, "__start_notes\n"))
- *notes = *end;
+ while (read_address (&state, &addr) && addr >= *start)
+ {
+ *end = addr;
+ if (*notes == 0 && !strcmp (state.p, "__start_notes\n"))
+ *notes = *end;
+ }
Dwarf_Addr round_kernel = sysconf (_SC_PAGESIZE);
*start &= -(Dwarf_Addr) round_kernel;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libdw/26177] eu-unstrip -n -k fails on kernels 4.14-4.19
https://sourceware.org/bugzilla/show_bug.cgi?id=26177 --- Comment #2 from Vitaly Chikunov --- Yes, your fix works for me too. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/26176] Backend modules of elfutils are always linked to shared library
https://sourceware.org/bugzilla/show_bug.cgi?id=26176 --- Comment #3 from Mark Wielaard --- (In reply to maarten from comment #2) > Thanks for the quick reply! > > First, some background what we are trying to do: > package elfutils using a conan recipe at > https://github.com/conan-io/conan-center-index/pull/1768 > > We would like to provide elfutils as a static and shared library. Note that we already produce both a shared and static version of libelf.so/libelf.a, libdw.so/libdw.a and libasm.so/libasm.a in out current build. Although the static version of libdw.a didn't really work correctly till 0.180 because it was using dlopen. I was actually going to propose we wouldn't build the static version by default because I didn't think anybody is actually using it. What is your use case? And would it be a problem if we dropped building the static libraries by default, and you had to explicitly build the package with static libs? > The original version we were trying to add was 0.173, but I just updated it > to 0.180 which indeed does not have loadable modules. > > So my problem is indeed gone! Nice. > Some things we had to patch: > > - enable static builds (regardless of gprof or gcov configuration) Yes, these are odd and almost never used. Once every release we build with gcov to generate the https://sourceware.org/elfutils/coverage/ but those builds are not really tested otherwise. > - disable -Werror What errors/warnings are you seeing? > Also, it looks like `libasm.h` and `libdwfl.h` use types defined in > `gelf.h`, but do not include the header. There was an issue in libasm.h which got fixed in elfutils-0.178-24-g287a1845 libdwfl.h includes libdw.h which includes gelf.h so should be usable standalone. > Some feedback/comments about these patches would be appreciated. Could you attach concrete patches to this bug report? -- You are receiving this mail because: You are on the CC list for the bug.
