Re: RISC-V disassembler

On 9/7/19 2:18 AM, Ulrich Drepper wrote: I'll check in the attached patch which implements a disassembler for RISC-V. It also fixes a problem in the x86 disassember, exposed through the additions needed for RISC-V. Since aside rth, who added the BPF disassembler, no one beside me ever worked on

Re: [PATCH] RISC-V: Add initial return value location support.

On Thu, Jan 10, 2019 at 4:26 AM Mark Wielaard wrote: > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#procedure-calling-convention > But I couldn't find an official DWARF register mapping. > If you have references I like to add them to the code. This document now has a chap

Re: RISC-V support

On Sat, Jan 12, 2019 at 5:23 PM Kurt Roeckx wrote: > O32 really has at least the following variants: > - O32 FP32 > - O32 FPXX > - O32 FP64 > - O32 FP64A The FPXX and FP64A stuff is new, after I stopped tracking MIPS stuff, so I hadn't noticed it. I see why they added these, but if you count sof

Re: RISC-V support

On Sat, Jan 12, 2019 at 3:21 PM Kurt Roeckx wrote: > > But how many are actually used? Which does Debian support? > > I'm not at all an export of mips, I really don't know that much > about it. It depends on how you count ABIs, but yes there have unfortunately been a lot of them over the years.

Re: [PATCH] RISC-V: Add untested 32-bit core file support.

On Sat, Jan 12, 2019 at 2:29 PM Mark Wielaard wrote: > I don't really like adding code that cannot be tested. But it does look > the 32-bit port isn't far off, just waiting for the next linux/glibc > release to settle the time_t ABI. And the code does look correct. > Except for... We don't expect

Re: [PATCH] RISC-V: Add initial return value location support.

On Thu, Jan 10, 2019 at 4:26 AM Mark Wielaard wrote: > We really should add a non-native test, so it is easier to test on > other arches. But currently only aarch64 has one (run-funcretval.sh). > I'll see if I can extend that to other arches. Then we can also see if > we can get the aggregates cor

Re: [PATCH] RISC-V: Add initial return value location support.

On Thu, Jan 10, 2019 at 4:26 AM Mark Wielaard wrote: > The comments explain things well, but it would be good to have official > references to the calling convention and DWARF register mappings. > The calling convention is explained in: > > https://github.com/riscv/riscv-elf-psabi-doc/blob/master/

Re: RISC-V support

On Tue, Jan 8, 2019 at 5:52 AM Mark Wielaard wrote: > The _start one seems to be: > https://sourceware.org/bugzilla/show_bug.cgi?id=23125 > So that is fixed with glibc 2.29. > > Do you have a bug for the second issue with __thread_start? https://sourceware.org/bugzilla/show_bug.cgi?id=24040 I pl

[PATCH] RISC-V: Add untested 32-bit core file support.

This conflicts with the previoues two patches. Adds 32-bit support exactly the same way that the sparc backend handles 32- and 64-bit core file support. The 64-bit core file support was tested and still works same as before. Signed-off-by: Jim Wilson --- backends/ChangeLog | 11

[PATCH] RISC-V: Add initial return value location support.

g the hook. Signed-off-by: Jim Wilson --- backends/ChangeLog | 8 ++ backends/Makefile.am| 2 +- backends/riscv_init.c | 10 +- backends/riscv_retval.c | 251 4 files changed, 269 insertions(+), 2 deletions(-) create mode 100644 bac

[PATCH] RISC-V: Improve riscv64 core file support.

This fixes two problems. The offset for x1 is changed from 1 to 8 because this is a byte offset not a register skip count. Support for reading the PC value is added. This requires changing the testsuite to match the new readelf output for coredumps. Signed-off-by: Jim Wilson --- backends

RISC-V support

I'm looking at the RISC-V elfutils support to help the Debian folks. I see four testcases failing, same as Kurt Roeckx reported about 6 weeks ago. I'm testing on a Fedora Core 29 system. I found a trivial bug in backends/riscv_corenote.c. It has ".offset = 1" but this is a byte offset not a regi