linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).