This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [PATCH 0/4] s390 improvements
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: rth at twiddle dot net (Richard Henderson)
- Cc: libffi-discuss at sourceware dot org, Ulrich dot Weigand at de dot ibm dot com, vogt at linux dot vnet dot ibm dot com, krebbel at linux dot vnet dot ibm dot com
- Date: Fri, 19 Dec 2014 16:06:48 +0100 (CET)
- Subject: Re: [PATCH 0/4] s390 improvements
- Authentication-results: sourceware.org; auth=none
Richard Henderson wrote:
> This is relative to Dominik's patch from the 16th. The complete
> tree can be found at
>
> git://github.com/rth7680/libffi.git s390
>
> Mostly relevant is patch 3, which converts the s390 port to the
> more modern arrangement where there's no callback into ffi_prep_args.
This is a bit confusing to me. The assembler routine now does:
lg %r15,120(%r2) # Set up outgoing stack
without ever restoring the initial stack pointer before returning
to its caller. This probably works right now since the value loaded
here is determined like that:
/* Pass the outgoing stack frame in the r15 save slot. */
frame->gpr_save[8] = (unsigned long)(stack - sizeof(struct call_frame));
and since "stack" was allocated via alloca and ffi_call_int does not
require an argument save area when calling any of its subroutines,
the stack pointer value computed here should always in fact be
identical to the value %r15 already has at the above location.
Using the 160 bytes below "stack" as register save area for use of the
target function called by ffi_call_SYSV is also only safe if those bytes
are in fact the register save area ffi_call_int provides for its caller,
e.g. again if the value is already identical to %r15. (If this were
any other value, we might clobber parts of ffi_call_int's stack frame
that it conceivably might still access.)
However, if the procedure only works if the "lg" is a nop, why is it
even done? Also, the whole setup seems a bit fragile since changes
to ffi_call_int might cause it to need an argument save area ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com