From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Keith Packard" <keithp@keithp.com>,
qemu-arm <qemu-arm@nongnu.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: Semihosting, arm, riscv, ppc and common code
Date: Wed, 15 Jan 2020 12:17:35 +1100 [thread overview]
Message-ID: <3ab2ca1f7a9b37b201a58f3a817edc5193e8b1f4.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAFEAcA-A_caQgwi5DzExdZChoTg-Qa73hq7Ho7dPLiN633Yj1Q@mail.gmail.com>
On Tue, 2020-01-14 at 09:59 +0000, Peter Maydell wrote:
> Note that semihosting is not a "here's a handy QEMU feature"
> thing. It's an architecture-specific API and ABI, which should
> be defined somewhere in a standard external to QEMU.
There is no such standard for powerpc today that I know of.
> You need to start by having a definition for PPC of what
> semihosting is. If you're starting from scratch there, there
> are some important things you should do differently to Arm --
> there is no benefit to repeating the mistakes of API definition
> that we made! Most notably, you want to specify and require
> that any unrecognized semihosting call function fails in a
> clean and detectable way; you also should have a semihosting
> function for "ask for a feature bit mask" so you don't need
> the silly magic-filename approach Arm had to go for. You
> also want to standardize what the errno values are, which Arm
> forgot to do and which makes the errno handling in the spec
> pretty useless.
Keith and I are somewhat of a different mind here. From the perspective
of the user of that API (picolibc is one), it's easier to deal with a
single one and have everybody inherit the same bugs.
Now I understand the point of wanting to fix the mistakes made but I
would suggest we do so by proposing extensions to the existing one to
do so.
> TLDR: don't start by writing code, start by writing the *API/ABI
> spec*.
> I tried to push the RISCV folks in this direction as well.
AFAIK they are still just doing what ARM does for the above reason.
Cheers,
Ben.
next prev parent reply other threads:[~2020-01-15 1:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 6:25 Semihosting, arm, riscv, ppc and common code Benjamin Herrenschmidt
2020-01-14 7:32 ` Liviu Ionescu
2020-01-14 7:53 ` Benjamin Herrenschmidt
2020-01-14 9:51 ` Alex Bennée
2020-01-15 1:14 ` Benjamin Herrenschmidt
2020-01-15 12:01 ` Alex Bennée
2020-01-15 12:30 ` Liviu Ionescu
2020-01-15 21:28 ` Richard Henderson
2020-01-15 22:02 ` Liviu Ionescu
2020-01-16 2:04 ` Benjamin Herrenschmidt
2020-01-16 7:57 ` Liviu Ionescu
2020-01-16 6:33 ` Benjamin Herrenschmidt
2020-01-14 9:59 ` Peter Maydell
2020-01-15 1:17 ` Benjamin Herrenschmidt [this message]
2020-01-15 13:32 ` Peter Maydell
2020-01-16 2:01 ` Benjamin Herrenschmidt
2020-01-16 11:05 ` Peter Maydell
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=3ab2ca1f7a9b37b201a58f3a817edc5193e8b1f4.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=alex.bennee@linaro.org \
--cc=keithp@keithp.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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 NNTP newsgroup(s).