[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary

2021-05-01 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1

[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary

2021-05-05 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 --- Comment #3 from Jim Wilson --- My first thought was linkonce/comdat, but that is used by C++ and would have shown up before. So that leaves -gc-sections. I can reproduce with a simple example. rohan:2010$ cat tmp.c extern int sub1 (int)

[Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary

2021-05-05 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27805 --- Comment #4 from Jim Wilson --- Actually I just noticed with the x86_64-linux compiler I'm getting addresses of 0 but lengths of 4 which would be OK. Length: 92 Version: 2 Offset into .debug_info:

[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI

2021-09-19 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #3 from Jim Wilson --- I'm not aware of any supported lp64 linux systems, so I don't know why the patch is needed, and I am unable to test it. It does look mostly reasonable. The riscv_init.c change isn't quite correct as we have

[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI

2021-09-19 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #5 from Jim Wilson --- I hadn't thought about the kernel. It is compiled LP64 and with the FP extensions disabled, to avoid accidentally using FP registers. It does save/restore FP registers in the context switching code, but oth

[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI

2021-09-23 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #8 from Jim Wilson --- Calling convention docs: https://github.com/riscv-non-isa/riscv-elf-psabi-doc Recently converted from markdown to asciidoc. The releases link on the right contains pdf files which are likely the easiest way

[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI

2021-09-23 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #9 from Jim Wilson --- The patch looks OK to me. In the old code, for float and double (not complex) we call pass_in_fpr_lp64d because it returns the same result as pass_in_fpr_lp64f and not worth an extra check for that. In the

[Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI

2021-09-29 Thread wilson at gcc dot gnu.org via Elfutils-devel
https://sourceware.org/bugzilla/show_bug.cgi?id=27925 --- Comment #11 from Jim Wilson --- Userspace is lp64d. The kernel is lp64. You can't create an lp64 binary because there are no lp64 start files or libraries. The kernel can be linked because it doesn't require any start files or libraries