[PATCH 00/33] Build ppc64le kernel using ABIv2

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Wed Mar 26 00:18:19 EST 2014


Anton Blanchard <anton at samba.org> wrote on 25.03.2014 12:44:06:

> There are two known outstanding issues:
>
> - If a kernel module calls into an exported assembly function
>   which in turns calls out to C, r2 is going to be wrong. One example
>   is __copy_tofrom_user_power7.
>
>   The reason is _GLOBAL() doesn't have a global entry point setup
>   with the associated addis/addi used to create r2. I tried adding
>   it and quickly realised that _GLOBAL is used places that will not
>   tolerate the addi/addis (eg __start()).

You probably should have two different macros _GLOBAL_TOC vs. _GLOBAL
(or _GLOBAL vs. _GLOBAL_NOTOC), and use the variant that provides a
global entry point setting up the TOC only with those functions that
actually require a TOC.

> - arch/powerpc/platforms/pseries/hvCall.S assumes we always have a
>   parameter save area, which is incorrect for ABIv2. I tried to be
>   intelligent and use the toc save area to store some information
>   but that failed as soon as we started using modules. It would be
>   nice to avoid a stack frame in the common (tracepoints disabled)
>   case, but we may end up having to allocate one.

When I looked at this last time, I remarked:

>./platforms/pseries/hvCall.S:
>./platforms/cell/beat_hvCall.S:
>Looks safe since all functions are called via varargs prototypes
>(or > 8 integer arguments).

Checking again, this still seems true.  These are the prototypes
for all the functions in hvCall.S:

long plpar_hcall_norets(unsigned long opcode, ...);
long plpar_hcall(unsigned long opcode, unsigned long *retbuf, ...);
long plpar_hcall_raw(unsigned long opcode, unsigned long *retbuf, ...);
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...);

Functions like that *will* always have a save area allocated by
the caller, even in the ELFv2 ABI.

Am I missing something here?

Bye,
Ulrich



More information about the Linuxppc-dev mailing list