public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "wilson at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug backends/27925] riscv backend only provides return value locations for code compiled for LP64D ABI
Date: Sun, 19 Sep 2021 16:45:26 +0000	[thread overview]
Message-ID: <bug-27925-10460-RC7CUeEZ89@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-27925-10460@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=27925

--- Comment #3 from Jim Wilson <wilson at gcc dot gnu.org> ---
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 3 64-bit ABIs.  lp64d is 64-bit FP registers, lp64f is 32-bit FP
registers, and lp64 is no FP registers.  So we actually need a check for the
lp64 ABI instead of assuming that !lp64d is lp64.  Also the "lp64i" should be
"lp64" to be consistent with the ABI naming scheme.

I would suspect other changes are required for full lp64 support. 
riscv_abi_cfi references FP registers unconditionally.  riscv_register_info
references FP registers unconditionally.

The lp64 and lp64f support is incomplete because I've never had access to a
system where I can do the necessary work.  Similarly, the ilp32, ilp32f, and
ilp64d support is also incomplete as I don't have access to any system I can
use to develop them.  All RISC-V linux desktop distros are lp64d.  I think the
linux kernel lacks support for ilp32f and lp64f so those may be impossible to
build at present.  There are some embedded linux distros that use the 32-bit
ABIs, and/or that use soft-float ABIs, but SiFive doesn't support those.  So
I'd have to build an entire linux distro from scratch and boot on qemu to set
up an environment just to do an elfutils port, and I haven't been willing to do
that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2021-09-19 16:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 18:58 [Bug backends/27925] New: " wcohen at redhat dot com
2021-09-18 21:18 ` [Bug backends/27925] " wcohen at redhat dot com
2021-09-19 10:30 ` mark at klomp dot org
2021-09-19 16:45 ` wilson at gcc dot gnu.org [this message]
2021-09-19 23:22 ` wcohen at redhat dot com
2021-09-20  2:29 ` wilson at gcc dot gnu.org
2021-09-20  7:42 ` mark at klomp dot org
2021-09-23  3:26 ` wcohen at redhat dot com
2021-09-23 14:22 ` wilson at gcc dot gnu.org
2021-09-23 14:30 ` wilson at gcc dot gnu.org
2021-09-29 13:43 ` mark at klomp dot org
2021-09-29 17:02 ` wilson at gcc dot gnu.org
2021-09-29 20:13 ` wcohen at redhat dot com
2021-09-29 22:14 ` mark at klomp dot org

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=bug-27925-10460-RC7CUeEZ89@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@sourceware.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).