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: Wed, 29 Sep 2021 17:02:42 +0000	[thread overview]
Message-ID: <bug-27925-10460-Q4uuOzt0dt@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 #11 from Jim Wilson <wilson at gcc dot gnu.org> ---
Userspace is lp64d.  The kernel is lp64.  You can't create an lp64 binary
because there are no lp64 start files or libraries.  The kernel can be linked
because it doesn't require any start files or libraries.  The riscv backend is
using the ELF header flags to determine if a binary is lp64 or lp64d, so if you
can't create an lp64 binary you can't run an lp64 test.  Similarly, you also
can't construct and run lp64f, ilp32, ilp32f, or ilp32d ABI tests for the same
reason.

The difference between lp64 and lp64d is that FP values are passed in integer
regs in the first and FP regs in the second.  If you aren't testing FP values,
then you aren't properly testing the lp64 ABI.  Though given that the kernel is
compiled soft-float, such testing would be sufficient for using elfutils with
an lp64 kernel, but not for a lp64 user space.

The best way to test the lp64 ABI support is to build an entire linux system
from scratch using an lp64 userspace.  You can then natively test the lp64
support. 
 Likewise for lp64f, ilp32, ilp32f, and ilp32d.  That is outside the scope of
this bug report.

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

  parent reply	other threads:[~2021-09-29 17:02 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
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 [this message]
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-Q4uuOzt0dt@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).