[Bug libdw/22452] Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module
https://sourceware.org/bugzilla/show_bug.cgi?id=22452 --- Comment #10 from H. Brueckner --- (In reply to Mark Wielaard from comment #9) > (In reply to H. Brueckner from comment #8) > > (In reply to Mark Wielaard from comment #5) > > > (In reply to Mark Wielaard from comment #4) > > > > So, if you could provide the output of eu-readelf --relocs paes_s390.ko > > > > (on > > > > your combined paes_s390.ko containing both code and debug) that would be > > > > helpful. > > > > > > eu-readelf --debug-dump=frames --relocs paes_s390.ko > > > > > > > Just attached the output; also the output of the binutils readelf command > > for comparision. I guess that there are some more issues because lots of > > invalid relocations are listed. > > Is that eu-readelf from a distro install? Then there is something wrong with > that install. If it is a build from source then make sure LD_LIBRARY_PATH > contains the backends directory that has libebl_s390.so. Otherwise > eu-readelf won't know about machine specific ELF/DWARF mappings (like the > relocation types/names). It was a local built and install, the LD_LIBRARY_PATH was not set properly. However, setting is correctly, the relocation are displayed like with readelf. Will update the attachment soon. > > But the output does confirm what I feared. The R_390_PC32 .rela.eh_frame > relocations are not "simple". They are load based. So now it comes to that point I have feared, as it looks like the libdw just performs "simple" relocations. Your comment and the ebl_reloc_simple_type() call in libdwfl/relocate.c proofs that. Anyhow, do you plan to extend the relocation code to support more complex relocations tool? > It might not be too hard to add support for those. What needs to be done / is necessary for that? > But if there is any > possibility to generate .debug_frame based CFI for the s390x kernel modules > that would IMHO a much better/simpler solution because it makes things more > in line with other arches. It should also make the kernel modules smaller. > Does anything actually use the loaded .eh_frame CFI on s390x? I will check the module usage on .eh_frame and will have a try on including the CFI in the .debug_frame. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/22452] Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module
https://sourceware.org/bugzilla/show_bug.cgi?id=22452 --- Comment #11 from Andreas Krebbel --- x86 enables generation of .debug_frame by using: KBUILD_CFLAGS += -fno-asynchronous-unwind-tables in the kernel Makefile. This makes GCC to add ".cfi_sections .debug_frame" to the assembler output which in turn triggers gas to generate the section. I don't see a reason why we couldn't do the same for s390. The .eh_frame section aren't used in the kernel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/22452] Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module
https://sourceware.org/bugzilla/show_bug.cgi?id=22452 --- Comment #12 from Mark Wielaard --- (In reply to H. Brueckner from comment #10) > (In reply to Mark Wielaard from comment #9) > > But the output does confirm what I feared. The R_390_PC32 .rela.eh_frame > > relocations are not "simple". They are load based. > > So now it comes to that point I have feared, as it looks like the libdw just > performs "simple" relocations. Your comment and the ebl_reloc_simple_type() > call in libdwfl/relocate.c proofs that. Anyhow, do you plan to extend the > relocation code to support more complex relocations tool? > > > It might not be too hard to add support for those. > > What needs to be done / is necessary for that? We would need to extend ebl_reloc_simple_type, or add a new ebl backend hook, that signals a relocation uses the load address. Then in libdwfl/relocate.c use that to adjust the value to include the load address that libdwfl assigns to the section (given by struct dwfl_relocation start). This is similar to what arch/s390/kernel/module.c in the kernel does, but slightly more complicated because we want it to work "offline" cross architecture. This would be helpful in general for any ET_REL file for which we want to inspect the .eh_frame section CFI data. But since this is just for the kernel modules at the moment I would wait with implementing it till you have experimented with adjusting the kernel build like suggested in comment #11. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libdw/22452] Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module
https://sourceware.org/bugzilla/show_bug.cgi?id=22452 --- Comment #13 from Andreas Krebbel --- The .eh_frame section in an .o file uses PC-relative relocations in order to get its offset to the code determined during final link step. It probably does this to avoid runtime relocations which would be necessary for an absolute relocation. .eh_frame is read-only in the mapping, so runtime relocs are not supposed to occur after final link step. Since in the kernel module scenario libdw has to deal with the .eh_frame section from the .o file it encounters these PC-relative relocs which it cannot handle. I agree with Mark that libdw does not really need to support these relocs since they only occur in that weird scenario which can be avoided using .debug_frame instead. .debug_frame does not have a location in the address space so a PC-relative relocation would be pointless. Instead it is supposed to be read by tools where applying absolute relocs is no problem. -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] libdwfl: Don't dereference possibly unaligned auxv entry pointer from core.
The notes in a core file that contain the auxv entries might not be
naturally aligned. The code already tried to account for that, but
the GCC 8 undefined behaviour sanitizer found we were till dereferencing
the actual auxv entry pointer directly. Fix this by calculating all pointers
by hand and not use an array of auxv entries trick.
This makes make distcheck (which enables sanitize-undefined by default)
pass again using GCC8.
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 12
libdwfl/link_map.c | 38 +++---
2 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index 112620f..d487ec1 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,15 @@
+2017-11-20 Mark Wielaard
+
+ * link_map.c (do_check64): Take a char * and calculate type and val
+ offsets before reading, possibly unaligned, values.
+ (do_check32): Likewise.
+ (check64): Remove define.
+ (check32): Likewise.
+ (auxv_format_probe): Call do_check32 and do_check64 directly with
+ a, possibly unaligned, auxv entry pointer.
+ (dwfl_link_map_report): Redefine AUXV_SCAN to not dereference a
+ possibly unaligned auxv entry pointer.
+
2017-10-16 Mark Wielaard
* argp-std.c (parse_opt): For -k call argp_failure not failure to
diff --git a/libdwfl/link_map.c b/libdwfl/link_map.c
index 794668f..29307c7 100644
--- a/libdwfl/link_map.c
+++ b/libdwfl/link_map.c
@@ -43,13 +43,14 @@
static inline bool
-do_check64 (size_t i, const Elf64_auxv_t (*a64)[], uint_fast8_t *elfdata)
+do_check64 (const char *a64, uint_fast8_t *elfdata)
{
/* The AUXV pointer might not even be naturally aligned for 64-bit
data, because note payloads in a core file are not aligned. */
-
- uint64_t type = read_8ubyte_unaligned_noncvt (&(*a64)[i].a_type);
- uint64_t val = read_8ubyte_unaligned_noncvt (&(*a64)[i].a_un.a_val);
+ const char *typep = a64 + offsetof (Elf64_auxv_t, a_type);
+ uint64_t type = read_8ubyte_unaligned_noncvt (typep);
+ const char *valp = a64 + offsetof (Elf64_auxv_t, a_un.a_val);
+ uint64_t val = read_8ubyte_unaligned_noncvt (valp);
if (type == BE64 (PROBE_TYPE)
&& val == BE64 (PROBE_VAL64))
@@ -68,16 +69,15 @@ do_check64 (size_t i, const Elf64_auxv_t (*a64)[],
uint_fast8_t *elfdata)
return false;
}
-#define check64(n) do_check64 (n, a64, elfdata)
-
static inline bool
-do_check32 (size_t i, const Elf32_auxv_t (*a32)[], uint_fast8_t *elfdata)
+do_check32 (const char *a32, uint_fast8_t *elfdata)
{
/* The AUXV pointer might not even be naturally aligned for 32-bit
data, because note payloads in a core file are not aligned. */
-
- uint32_t type = read_4ubyte_unaligned_noncvt (&(*a32)[i].a_type);
- uint32_t val = read_4ubyte_unaligned_noncvt (&(*a32)[i].a_un.a_val);
+ const char *typep = a32 + offsetof (Elf32_auxv_t, a_type);
+ uint32_t type = read_4ubyte_unaligned_noncvt (typep);
+ const char *valp = a32 + offsetof (Elf32_auxv_t, a_un.a_val);
+ uint32_t val = read_4ubyte_unaligned_noncvt (valp);
if (type == BE32 (PROBE_TYPE)
&& val == BE32 (PROBE_VAL32))
@@ -96,26 +96,22 @@ do_check32 (size_t i, const Elf32_auxv_t (*a32)[],
uint_fast8_t *elfdata)
return false;
}
-#define check32(n) do_check32 (n, a32, elfdata)
-
/* Examine an auxv data block and determine its format.
Return true iff we figured it out. */
static bool
auxv_format_probe (const void *auxv, size_t size,
uint_fast8_t *elfclass, uint_fast8_t *elfdata)
{
- const Elf32_auxv_t (*a32)[size / sizeof (Elf32_auxv_t)] = (void *) auxv;
- const Elf64_auxv_t (*a64)[size / sizeof (Elf64_auxv_t)] = (void *) auxv;
-
for (size_t i = 0; i < size / sizeof (Elf64_auxv_t); ++i)
{
- if (check64 (i))
+ if (do_check64 (auxv + i * sizeof (Elf64_auxv_t), elfdata))
{
*elfclass = ELFCLASS64;
return true;
}
- if (check32 (i * 2) || check32 (i * 2 + 1))
+ if (do_check32 (auxv + (i * 2) * sizeof (Elf32_auxv_t), elfdata)
+ || do_check32 (auxv + (i * 2 + 1) * sizeof (Elf32_auxv_t), elfdata))
{
*elfclass = ELFCLASS32;
return true;
@@ -717,8 +713,12 @@ dwfl_link_map_report (Dwfl *dwfl, const void *auxv, size_t
auxv_size,
const Elf##NN##_auxv_t *av = auxv;\
for (size_t i = 0; i < auxv_size / sizeof av[0]; ++i) \
{ \
- uint##NN##_t type = READ_AUXV##NN (&av[i].a_type);\
- uint##NN##_t val = BL##NN (READ_AUXV##NN (&av[i].a_un.a_val)); \
+ const char *typep = auxv + i * sizeof (Elf##NN##_auxv_t); \
+ typep += offsetof (Elf##NN##_auxv_t, a_type); \
+ uint##NN##_t type = READ_AUXV##NN (typep);\
+ const char *valp = auxv + i * sizeo
[Bug libdw/22452] Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module
https://sourceware.org/bugzilla/show_bug.cgi?id=22452 --- Comment #14 from H. Brueckner --- Hi Mark, Andreas, (In reply to Andreas Krebbel from comment #11) > x86 enables generation of .debug_frame by using: > > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables > > in the kernel Makefile. This makes GCC to add ".cfi_sections .debug_frame" > to the assembler output which in turn triggers gas to generate the section. > > I don't see a reason why we couldn't do the same for s390. The .eh_frame > section aren't used in the kernel. Thanks for this direction: Emitting the CFI data in the .debug_frame work nicely. With that change, perf probe and my test program works. For reference: ./ko-func-call-frame-cfa xts_paes_crypt ~/git/linux/arch/s390/crypto/paes_s390.ko I: Looking up xts_paes_crypt@/root/git/linux/arch/s390/crypto/paes_s390.ko DIE: name=xts_paes_crypt tag=subprogram offset=53957 (0xd2c5) low pc: 10ca8 high pc: 10e78 entry pc: 10ca8 I: Frame Base: Number of locations: 1 (len=1) I: Frame Base: Location operation 0: call_frame_cfa E: Could not obtain CFI (eh): no DWARF information I: CFA operation: 0: bregx clearly shows a successful call to dwarf_frame_cfa() obtaining the CFI from the .debug_frame (and not longe from the .eh_frame). Having explicit ebl hooks would still be nice but I guess will not be the top-priority item in the TODO list. I pursue to integrate my change for s390 in the upstream kernel. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
