[Bug libdw/22452] Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module

[krebbel at linux dot vnet.ibm.com]

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

[krebbel at linux dot vnet.ibm.com]

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.