All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=segher@kernel.crashing.org \
    --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.