From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45061 invoked by alias); 8 Jan 2019 13:52:42 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 45043 invoked by uid 89); 8 Jan 2019 13:52:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Jim, exciting, odp, noticed X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Jan 2019 13:52:36 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id F2A6D323AB45; Tue, 8 Jan 2019 14:52:33 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id A60E1400E989; Tue, 8 Jan 2019 14:52:33 +0100 (CET) Message-ID: Subject: Re: RISC-V support From: Mark Wielaard To: Jim Wilson , elfutils-devel@sourceware.org Cc: Karsten Merker Date: Tue, 08 Jan 2019 13:52:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00008.txt.bz2 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 =3D > 1" but this is a byte offset not a register offset, so it needs to be > ".offset =3D 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=3D23125 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. >=20 > 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. >=20 > 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=3Delfutils.git;a=3Dblob_plain;f=3DCONTRIBUTING If not, please look through it, we are fairly easy on contributions, just m= ake 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