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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.