Re: RISC-V support

[Mark Wielaard <mark at klomp dot org>]

Hi Jim,

Apologies for the late reply, holiday season.
Seeing some patches already posted I think you already found the
answers to your questions, but just to be sure, lets answer this email
before reviewing the actual patches.

On Wed, 2018-12-26 at 18:29 -0800, Jim Wilson wrote:
> 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.

This is very exciting, I had no idea RISC-V was already so complete. I
just installed a fedora stage 4 image using libvirt/qemu. It is
somewhat slow (elfutils build still running), but seems very complete.

> I found a trivial bug in backends/riscv_corenote.c.  It has ".offset =
> 1" but this is a byte offset not a register offset, so it needs to be
> ".offset = 8" instead.  I also added in the missing PC support.  These
> two fixes then require a fix for tests/run-readelf-mixed-corenote.sh
> because the eu-readelf output is now more correct than before.

Thanks.

> There is also a missing backends/riscv_retval.c file.  I have an
> initial implementation for this, but I haven't implemented the support
> for structures with one or two float fields yet, as this gets a little
> complicated.

Support for just the basic types is already very useful. This is used
for example by systemtap for return probes.

> With these patches, I now see two failures.  One is a glibc bug that
> Andreas Schwab already fixed, where _start fails to terminate the
> unwind chain.  I just don't have this patch on my system.  The other
> failure is the same glibc bug in __thread_start, which apparently
> isn't fixed yet, and needs the same fix Andreas already added to
> _start.  So with the appropriate glibc fixes, the elfutils testsuite
> should run without error on a riscv64/lp64d system using the patches
> I
> have.

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?

My build finally finished. autoreconf && configure && make -j2 && make
check -j2 took 25 minutes. It is using glibc 2.27.9000. I'll see if I
can upgrade it somehow.

It would be nice to have some riscv setup for our buildbot. Do you
happen to have recommendations for something like that? Any distro that
gets regular toolchain updates? Is a libvirt/qemu setup reliable enough
or would you recommend trying to get real hardware?

> There is a problem here though.  The riscv support was written to try
> to handle both 32-bit and 64-bit targets with a single elfutils
> backend.  But I have 6 ABIs I need to (theoretically) handle in
> riscv_retval.c.  The return_value_location function doesn't take any
> ebl or elf pointer, so I can't handle it there.  I can handle it in
> riscv_init.c by checking ebl and elf pointers there, and calling an
> appropriate function, but I'm not sure if that is OK.  Currently,
> none
> of the *_init.c files are using the elf pointer argument.

The ppc64 init does (to lookup the odp table which is necessary for
ppc64[be], but not ppc64le). It is allowed. And the backends/ebl
interface is completely internal, so feel free to suggest changes if
they make sense for riscv. If it is necessary we'll just update the
other backends.

> I noticed another problem which is that riscv_corenote.c is only
> correct for riscv64, because it assumes that registers are 64-bits.
> But I see that sparc has a solution for that, so I will have to take
> a
> closer look at that and see if I can make it work for riscv.
> 
> I unfortunately can't test the 32-bit riscv support.  We don't have
> working upstream support for 32-bit linux yet.  I can only test the
> 64-bit LP64D riscv support.
> 
> I haven't contributed to elfutils before.  So I'm looking for advice
> on how to proceed.  I can send out my work in progress patches if
> that
> is useful.  I probably should try to chop them up a bit first. I
> think
> I have 3 parts at the moment.  One part should be OK, and one part
> needs more work to be complete (but maybe incomplete is OK?), and one
> part I haven't written yet.

Looking at the patches you did sent it looks you already found the
CONTRIBUTING file:
https://sourceware.org/git/?p=elfutils.git;a=blob_plain;f=CONTRIBUTING
If not, please look through it, we are fairly easy on contributions, just make sure you read and agree to the Developer's Certfificate of Origin.

Partial patches are OK. But it is preferred to have them somewhat testable. Please don't contribute code that is completely theoretical and cannot be validated at all.

Thanks,

Mark