[Bug libdw/22452] New: 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 Bug ID: 22452 Summary: Failed to obtain CFI data for a OP_call_frame_CFA when looking for func entrypoc in an s390 kernel module Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: libdw Assignee: unassigned at sourceware dot org Reporter: brueckner at linux dot vnet.ibm.com CC: elfutils-devel at sourceware dot org Target Milestone: --- Created attachment 10612 --> https://sourceware.org/bugzilla/attachment.cgi?id=10612&action=edit ko-func-call-frame-cfa.c Problem --- The perf probe -m -V fails when looking up variables for a function defined in an s390 kernel module. I have attached a simple test program that performs these steps which results in problems to receive an CFI frame. Test Case and reproduction steps 1. Iterate through the DIE to spot a particular function 2. Determine frame base attribute for that function 3. Obtain location expressions for the frame base and entry pc of the function 4. The returned location expression is a DW_OP_call_frame_cfa 5. Obtain CFI from either eh_frame or debug_frame, which fails. 6. Obtain ops from dwarf_frame_cfa() The step 5 always fails for both, .eh_frame and debug_frame. When using dwarf_cfi_addrframe() on the .eh_frame, the resulting dwarf error message is "no matching address range". The attachment "ko-func-call-frame-cfa.c" contains this test case. Compile and link against ldw -lelf and issue with: ./ko-func-call-frame-cfa Note that this affects kernel modules built for s390. Running the test program against the s390 vmlinux image works fine, e.g., for the setup_arch function. As I cannot attach binary code, you can obtain an s390 kernel module, for example, from the kernel debuginfo packages of Fedora. For example: 1. https://download-ib01.fedoraproject.org/pub/fedora-secondary/releases/27/Server/s390x/debug/tree/Packages/k/kernel-debuginfo-4.13.9-300.fc27.s390x.rpm 2. rpm2cpio < kernel-debuginfo-4.13.9-300.fc27.s390x.rpm |cpio -id 3. Try to find details about the "xts_paes_crypt" function in paes_s390.ko.debug For example: ko-func-call-frame-cfa xts_paes_crypt kernel/arch/s390/crypto/paes_s390.ko.debug I: Looking up xts_paes_crypt@kernel/arch/s390/crypto/paes_s390.ko.debug DIE: name=xts_paes_crypt tag=subprogram offset=58750 (0xe57e) low pc: 10c18 high pc: 10dd6 entry pc: 10c18 I: Frame Base: Number of locations: 1 (len=1) I: Frame Base: Location operation 0: call_frame_cfa E: No CFI data available -- 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 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- I haven't investigated fully yet. But I did take a quick look at the paes_s390.ko.debug file. A few quick comments as early feedback. Note that it doesn't contain .debug_frame but only a .eh_frame section. Other architectures force .debug_frame for kernel modules to store the CFI. The .eh_frame is a loaded section, which means it won't go into the .debug file. So you would need to load the CFI from the main ELF .ko. One tricky issue here is the fact that kernel modules are ET_REL files that still need relocations applied (you can see there is also a .rela.eh_frame section). libdwfl can do simple relocations, but might not know about all relocation types used in an .eh_frame section (I haven't checked yet). -- 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 #2 from H. Brueckner --- (In reply to Mark Wielaard from comment #1) > I haven't investigated fully yet. > But I did take a quick look at the paes_s390.ko.debug file. > A few quick comments as early feedback. > > Note that it doesn't contain .debug_frame but only a .eh_frame section. > Other architectures force .debug_frame for kernel modules to store the CFI. > > The .eh_frame is a loaded section, which means it won't go into the .debug > file. So you would need to load the CFI from the main ELF .ko. Initially, I have tried on my own kernel build (including debug_info) and ran the test program against the .ko file. (Because I am not permitted to share binary code and, please, do not ask why, it is difficult to provide you an alternative. If you have access to a s390 or use a cross-compiler it would be fine but that typically requires some effort on your side. In any case, if you require some output in text form, please let me know. > One tricky issue here is the fact that kernel modules are ET_REL files > that still need relocations applied (you can see there is also a > .rela.eh_frame section). libdwfl can do simple relocations, but might not > know about all relocation types used in an .eh_frame section (I haven't > checked yet). Ok. -- 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 #3 from H. Brueckner --- (In reply to Mark Wielaard from comment #1) > One tricky issue here is the fact that kernel modules are ET_REL files > that still need relocations applied (you can see there is also a > .rela.eh_frame section). libdwfl can do simple relocations, but might not > know about all relocation types used in an .eh_frame section (I haven't > checked yet). At least, I checked the reloc types for s390 (backends/s390_reloc.def) and the list is complete wrt kernel modules. Not sure if there is further work to be done for non-simple relocations. -- 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 #4 from Mark Wielaard --- (In reply to H. Brueckner from comment #2) > (In reply to Mark Wielaard from comment #1) > > The .eh_frame is a loaded section, which means it won't go into the .debug > > file. So you would need to load the CFI from the main ELF .ko. > > Initially, I have tried on my own kernel build (including debug_info) and > ran the test program against the .ko file. (Because I am not permitted to > share binary code and, please, do not ask why, it is difficult to provide > you an alternative. If you have access to a s390 or use a cross-compiler it > would be fine but that typically requires some effort on your side. Don't worry, we have the split .ko/.debug files, it should in theory also work (or show the same bug) with that. > In any case, if you require some output in text form, please let me know. > > > One tricky issue here is the fact that kernel modules are ET_REL files > > that still need relocations applied (you can see there is also a > > .rela.eh_frame section). libdwfl can do simple relocations, but might not > > know about all relocation types used in an .eh_frame section (I haven't > > checked yet). > > Ok. 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. If there are relocations in the .rela.eh_frame section that aren't "simple" as defined in s390_reloc_simple_type (backends/backends/s390_symbol.c) that might be a hint. Also if you could trick you kernel build to generate CFI in .debug_frame instead of .eh_frame like other arches seem to do, that would make a good testcase. -- 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 #5 from Mark Wielaard --- (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 would be even better. -- 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 #6 from H. Brueckner --- Created attachment 10613 --> https://sourceware.org/bugzilla/attachment.cgi?id=10613&action=edit paes_s390_ko-relocs-eu-readelf.txt using eu-readelf -- 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 #7 from H. Brueckner --- Created attachment 10614 --> https://sourceware.org/bugzilla/attachment.cgi?id=10614&action=edit paes_s390_ko-relocs-readelf.txt and what binutils readelfs reports for comparision -- 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 #8 from H. Brueckner --- (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 > > would be even better. 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. -- 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 #9 from Mark Wielaard --- (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 > > > > would be even better. > > 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). But the output does confirm what I feared. The R_390_PC32 .rela.eh_frame relocations are not "simple". They are load based. It might not be too hard to add support for those. 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? -- You are receiving this mail because: You are on the CC list for the bug.
