From: Florian Weimer <fweimer@redhat•com>
To: Segher Boessenkool <segher@kernel•crashing.org>
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 17:04:49 +0100 [thread overview]
Message-ID: <87o8unbm8u.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20200128154026.GI22482@gate.crashing.org> (Segher Boessenkool's message of "Tue, 28 Jan 2020 09:40:26 -0600")
* 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.
>
>> >> - Error handling: use of CR0[SO] to indicate error requires a mtcr / mtocr
>> >> instruction on the kernel side, and it is currently not implemented well
>> >> in glibc, requiring a mfcr (mfocr should be possible and asm goto support
>> >> would allow a better implementation). Is it worth continuing this style of
>> >> error handling? Or just move to -ve return means error? Using a different
>> >> bit would allow the kernel to piggy back the CR return code setting with
>> >> a test for the error case exit.
>> >
>> > 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.
>> >> - Should this be for 64-bit only? 'scv 1' could be reserved for 32-bit
>> >> calls if there was interest in developing an ABI for 32-bit programs.
>> >> Marginal benefit in avoiding compat syscall selection.
>> >
>> > 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?
>> > 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.
Thanks,
Florian
next prev parent reply other threads:[~2020-01-28 16:07 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 [this message]
2020-01-28 20:01 ` Segher Boessenkool
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=87o8unbm8u.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat$(echo .)com \
--cc=libc-alpha@sourceware$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=npiggin@gmail$(echo .)com \
--cc=segher@kernel$(echo .)crashing.org \
--cc=tuliom@linux$(echo .)ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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