powerpc Linux scv support and scv system call ABI proposal
Segher Boessenkool
segher at kernel.crashing.org
Fri Jan 31 22:55:14 AEDT 2020
Hi!
On Fri, Jan 31, 2020 at 08:30:45AM -0300, Adhemerval Zanella wrote:
> On 30/01/2020 18:41, Segher Boessenkool wrote:
> > On Thu, Jan 30, 2020 at 02:04:51PM -0300, Adhemerval Zanella wrote:
> >> be value propagated over
> >> functions calls and over different scopes, which I take from your
> >> explanation is not supported and fragile.
> >
> > You probably misundertand that, but let me ask: where is err assigned to
> > at all in the code you quoted? I don't see it. Maybe it's hidden in some
> > macro?
>
> Indeed it was not explicit in the example code, it is burried in the
> INTERNAL_SYSCALL_CALL macro which calls sparc-defined macros. For instance,
> with 6 argument kernel syscall, it issues:
>
> #define inline_syscall6(string,err,name,arg1,arg2,arg3,arg4,arg5,arg6) \
> ({ \
> register long __o0 __asm__ ("o0") = (long)(arg1); \
> register long __o1 __asm__ ("o1") = (long)(arg2); \
> register long __o2 __asm__ ("o2") = (long)(arg3); \
> register long __o3 __asm__ ("o3") = (long)(arg4); \
> register long __o4 __asm__ ("o4") = (long)(arg5); \
> register long __o5 __asm__ ("o5") = (long)(arg6); \
> err = name; \
> __asm __volatile (string : "=r" (err), "=r" (__o0) : \
> "0" (err), "1" (__o0), "r" (__o1), \
> "r" (__o2), "r" (__o3), "r" (__o4), \
> "r" (__o5) : \
> __SYSCALL_CLOBBERS); \
> __o0; \
> })
>
> Where 'err' defined by 'INTERNAL_SYSCALL_DECL' should be the 'err' macro
> argument.
GCC makes sure that what is in register g1 at the end of this asm does
end up in the C variable "err" (at least conceptually, the actual code
can be optimised further).
> I meant a register variable where its use 'after' the extended asm
> is expected to use the define register.
Yes, that is not supported like this. You'll have to use some more
inline asm at that use (with "err" as input there). Or, if you actually
care about this being in a specific register, maybe you shouldn't write
this in C at all? Writing assembler code in assembler language (in a
single inline asm block, or even in an assembler source file) tends to
give much better results (and is a lot easier) than trying to second-
guess the compiler. You can write pretty much anything as inline
assembler code, but that doesn't mean you have to, or that that would
be a good idea.
Things on the border like system calls are hard to handle. I like the
idea of doing those in compiler builtins ("compiler intrinsics"), but
that has its own problems as well: mostly, need to {write down / lock
down / determine in advance} more of the calling convention than the
other approaches. And of course it will take years before most projects
can use it :-/
Segher
More information about the Linuxppc-dev
mailing list