[Bug backends/27925] New: riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 Bug ID: 27925 Summary: riscv backend only provides return value locations for code compiled for LP64D ABI Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: backends Assignee: unassigned at sourceware dot org Reporter: wcohen at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- When diagnosing why a port of systemtap to riscv wasn't able to get $return values from functions I found that the elfutils riscv backend initialization code only sets up the return value location handler for the riscv for code that is compiled for hardware floating point (LP64D): https://sourceware.org/git/?p=elfutils.git;a=blob;f=backends/riscv_init.c;h=551e7bb6d3494a1627e98de91208ef8261af;hb=HEAD#l67 elfutils dwfl_module_return_value_location() should still be able to provide the location of the return value for riscv code for the other ABIs besides LP64D. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #1 from William Cohen --- Created attachment 13669 --> https://sourceware.org/bugzilla/attachment.cgi?id=13669&action=edit Possibe patch to provide return value information for lp64 abi This patch applies to elfutils 0.183 in fedora 33 and builds successfully. When running the systemtap examples testsuite there were a number of probe handlers that needed $return information what no longer complained about being unable to find the $return like the following with the patched elfutils for pfault.stp example: $ sudo ../install/bin/stap -v testsuite/systemtap.examples/memory/pfaults.stp Pass 1: parsed user script and 462 library scripts using 307316virt/76224res/10492shr/65720data kb, in 3020usr/560sys/3602real ms. Pass 2: analyzed script: 3 probes, 7 functions, 2 embeds, 7 globals using 422972virt/182640res/11412shr/181376data kb, in 10500usr/1900sys/12425real ms. Pass 3: translated to C into "/tmp/stapFHW9Zg/stap_aeb36ff31c1e99bccaad8645b97de810_4982_src.c" using 422972virt/182768res/11540shr/181376data kb, in 300usr/940sys/1247real ms. Pass 4: compiled C into "stap_aeb36ff31c1e99bccaad8645b97de810_4982.ko" in 51270usr/5930sys/51419real ms. Pass 5: starting run. ^CPass 5: run completed in 1350usr/2510sys/300065real ms. Previously with the unpatched elfutils: $ sudo ../install/bin/stap -v testsuite/systemtap.examples/memory/pfaults.stp Pass 1: parsed user script and 462 library scripts using 307316virt/76260res/10528shr/65720data kb, in 3710usr/640sys/4447real ms. semantic error: failed to retrieve return value location for handle_mm_fault [man error::dwarf] (mm/memory.c): identifier '$return' at /home/riscv/systemtap_write/install/share/systemtap/tapset/linux/memory.stp:91:15 source: fault_type = $return ^ Pass 2: analyzed script: 3 probes, 6 functions, 2 embeds, 7 globals using 422972virt/182872res/11644shr/181376data kb, in 12180usr/2310sys/14710real ms. Pass 2: analysis failed. [man error::pass2] -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #4 from William Cohen --- The patch was a first attempt to get something that addresses the issue. Thanks for pointing out where it needs improvements. Don't have a good way to test the issue in user-space so far as the 64-bit risc-v gcc environment seems the expect to have have floating point support. One way to test might to use perf to set up a probe point (https://www.brendangregg.com/perf.html), but I don't know if perf is using elfutils to get the return value location. Based on the pfault.stp example would have something like: sudo perf probe handle_mm_fault%return $retval sudo perf record -e probe:handle_mm_fault__return -aR sleep 1 sudo perf report sudo perf probe --del="handle_mm_fault__return" This issue occurs when using systemtap on the RISC-V linux kernel which doesn't link against the normal glibc runtime and takes steps to ensure that the floating point hardware is not used. Below is a example gcc commandline from a native build (note the -mabi=lp64 -march=rv64imac options): gcc -Wp,-MMD,arch/riscv/kernel/probes/.kprobes.o.d -nostdinc -isystem /usr/lib/gcc/riscv64-redhat-linux/10/include -I./arch/riscv/include -I./arch/riscv/include/generated -I./include -I./arch/riscv/include/uapi -I./arch/riscv/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -DCC_USING_PATCHABLE_FUNCTION_ENTRY -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mabi=lp64 -march=rv64imac -mno-save-restore -DCONFIG_PAGE_OFFSET=0xffe0 -mcmodel=medany -fno-omit-frame-pointer -mstrict-align -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fno-stack-protector -Wimplicit-fallthrough=5 -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-stack-clash-protection -g -fpatchable-function-entry=8 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -DKBUILD_MODFILE='"arch/riscv/kernel/probes/kprobes"' -DKBUILD_BASENAME='"kprobes"' -DKBUILD_MODNAME='"kprobes"' -D__KBUILD_MODNAME=kmod_kprobes -c -o arch/riscv/kernel/probes/kprobes.o arch/riscv/kernel/probes/kprobes.c -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #7 from William Cohen --- Created attachment 13676 --> https://sourceware.org/bugzilla/attachment.cgi?id=13676&action=edit Reworked risv retval patch I reworked that patch to add lp64f support and added lp64f support. I assumed that the lp64f falls back to passing doubles in integer register, but I didn't see that spelled out in the calling conventions (https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf). Is there some document that describes the lp64f calling conventions? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #12 from William Cohen --- The patch for the retval handling has been submitted. As mentioned in comment #9 testing is not trivial. Normal user-space executables are compiled with floating-point enabled and those executables work fine without the fixes. The LP64 and LP64F ABIs don't have the need start or libraries to compile user-space tests. Leaving the testsuite for later consideration. -- You are receiving this mail because: You are on the CC list for the bug.
