From: Jim Wilson <jimw@sifive.com>
To: elfutils-devel@sourceware.org
Cc: Karsten Merker <merker@debian.org>
Subject: RISC-V support
Date: Thu, 27 Dec 2018 02:29:00 -0000 [thread overview]
Message-ID: <CAFyWVaa3aixXz2zUN_aBSC9=CpkOXNPxCiun1MP-htghRqqwuw@mail.gmail.com> (raw)
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 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.
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.
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.
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.
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.
Jim
next reply other threads:[~2018-12-27 2:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-27 2:29 Jim Wilson [this message]
2019-01-08 13:52 ` Mark Wielaard
2019-01-08 19:28 ` Jim Wilson
2019-01-08 21:52 ` Karsten Merker
2019-01-11 23:23 ` Kurt Roeckx
2019-01-12 22:35 ` Mark Wielaard
2019-01-12 23:21 ` Kurt Roeckx
2019-01-13 1:06 ` Jim Wilson
2019-01-13 1:23 ` Kurt Roeckx
2019-01-13 22:15 ` Jim Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFyWVaa3aixXz2zUN_aBSC9=CpkOXNPxCiun1MP-htghRqqwuw@mail.gmail.com' \
--to=jimw@sifive.com \
--cc=elfutils-devel@sourceware.org \
--cc=merker@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).