[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