From: Segher Boessenkool <segher@kernel.crashing.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org,
Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
Nicholas Piggin <npiggin@gmail.com>
Subject: Re: powerpc Linux scv support and scv system call ABI proposal
Date: Tue, 28 Jan 2020 14:01:33 -0600 [thread overview]
Message-ID: <20200128200133.GJ22482@gate.crashing.org> (raw)
In-Reply-To: <87o8unbm8u.fsf@oldenburg2.str.redhat.com>
On Tue, Jan 28, 2020 at 05:04:49PM +0100, Florian Weimer wrote:
> * Segher Boessenkool:
>
> >> > I don't think we can save LR in a regular register around the system
> >> > call, explicitly in the inline asm statement, because we still have to
> >> > generate proper unwinding information using CFI directives, something
> >> > that you cannot do from within the asm statement.
> >
> > Why not?
>
> As far as I knowm there isn't a CFI directive that allows us to restore
> the CFI state at the end of the inline assembly. If we say that LR is
> stored in a different register than what the rest of the function uses,
> that would lead to incorrect CFI after the exit of the inline assembler
> fragment.
>
> At least that's what I think. Compilers aren't really my thing.
.cfi_restore? Or .cfi_remember_state / .cfi_restore_state, that is
probably easiest in inline assembler.
> >> > GCC does not model the condition registers,
> >
> > Huh? It does model the condition register, as 8 registers in GCC's
> > internal model (one each for CR0..CR7).
>
> But GCC doesn't expose them as integers to C code, so you can't do much
> without them.
Sure, it doesn't expose any other registers directly, either.
> >> > We don't have an ELFv2 ABI for 32-bit. I doubt it makes sense to
> >> > provide an ELFv1 port for this given that it's POWER9-specific.
> >
> > We *do* have a 32-bit LE ABI. And ELFv1 is not 32-bit either. Please
> > don't confuse these things :-)
> >
> > The 64-bit LE kernel does not really support 32-bit userland (or BE
> > userland), *that* is what you want to say.
>
> Sorry for the confusion. Is POWER9 running kernels which are not 64-bit
> LE really a thing in practice, though?
Linux only really supports 64-bit LE userland on p9. Anything else is
not supported.
> >> > From the glibc perspective, the major question is how we handle run-time
> >> > selection of the system call instruction sequence.
> >
> > Well, if it is inlined you don't have this problem either! :-)
>
> How so? We would have to put the conditional sequence into all inline
> system calls, of course.
Ah, if you support older systems in your program as well, gotcha. That
is not the usual case (just like people use -mcpu=power9 frequently,
which means the resulting program will not run on any older CPU).
Segher
next prev parent reply other threads:[~2020-01-28 20:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-28 10:50 powerpc Linux scv support and scv system call ABI proposal Nicholas Piggin
2020-01-28 13:09 ` Florian Weimer
2020-01-28 14:05 ` Nicholas Piggin
2020-01-28 15:40 ` Segher Boessenkool
2020-01-28 16:04 ` Florian Weimer
2020-01-28 20:01 ` Segher Boessenkool [this message]
2020-01-29 16:19 ` Florian Weimer
2020-01-29 16:29 ` Segher Boessenkool
2020-01-29 17:02 ` Florian Weimer
2020-01-29 17:51 ` Segher Boessenkool
2020-01-30 10:42 ` Florian Weimer
2020-01-30 11:25 ` Segher Boessenkool
2020-01-30 12:03 ` Florian Weimer
2020-01-30 13:50 ` Segher Boessenkool
2020-01-30 17:04 ` Adhemerval Zanella
2020-01-30 21:41 ` Segher Boessenkool
2020-01-31 11:30 ` Adhemerval Zanella
2020-01-31 11:55 ` Segher Boessenkool
2020-01-28 15:58 ` Florian Weimer
2020-01-29 4:41 ` Nicholas Piggin
2020-01-28 17:26 ` Adhemerval Zanella
2020-01-29 4:58 ` Nicholas Piggin
2020-01-29 13:20 ` Segher Boessenkool
2020-01-29 15:51 ` Tulio Magno Quites Machado Filho
2020-02-19 11:03 ` Nicholas Piggin
2020-01-28 22:14 ` Joseph Myers
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=20200128200133.GJ22482@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=tuliom@linux.ibm.com \
/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).