This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: libffi ABI change causes stack corruption on Debian
- From: Alan Modra <amodra at gmail dot com>
- To: Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Cc: Matthias Klose <matthias dot klose at canonical dot com>, libffi-discuss at sourceware dot org, Anthony Green <green at moxielogic dot com>
- Date: Thu, 21 Nov 2013 09:08:25 +1030
- Subject: Re: libffi ABI change causes stack corruption on Debian
- Authentication-results: sourceware.org; auth=none
- References: <OFCC53E675 dot 090279F5-ONC1257C29 dot 006A1ED2-C1257C29 dot 006B0A1A at de dot ibm dot com>
On Wed, Nov 20, 2013 at 08:29:09PM +0100, Ulrich Weigand wrote:
>
> Hi Matthias,
>
> the crashes you are seeing in powerpc Debian are caused by Alan's libffi
> patch. Specifically, the backport of this mainline patch:
> https://sourceware.org/ml/libffi-discuss/2013/msg00201.html
> which defines FFI_EXTRA_CIF_FIELDS to add an extra field to the ffi_cif
> data structure.
>
> The problem with this is that if libffi is used as shared library, the size
> of ffi_cif forms part of its ABI: the caller of libffi routines must
> provide an object of type ffi_cif when calling ffi_prep_cif. In the
> particular crashes I've been debugging, the caller was some routine in
> libgobject, which had not been recompiled, and so passes a too-small buffer
> to the new ffi_prep_cif, which then clobbers its caller's stack ...
>
> Alan, given that, I don't think it is OK to add new fields to
> FFI_EXTRA_CIF_FIELDS on any already existing platform ... Can you look
> into fixing this, either by handling vararg routines without extra fields
> in ffi_cif, or maybe by adding the new field only on powerpc64le? Thanks!
Shame on me for not thinking of these shared library issues..
ELFv2 needs those extra fields because ELFv2 doesn't always have a
parameter save area. Therefore we don't have the luxury of writing fp
values to both an fpr save area (used when passing fp values in fprs)
and the parameter save area (used when passing fp values on the
stack). This in turn means we must distinguish calls to functions
with variable arguments from calls to normal functions. Prior to the
patch series you identify above, powerpc libffi did not do that. So
to be backwards compatible, for ELFv1 I need to avoid use of the extra
fields and continue to write fp values to both fpr and parameter save
areas. This is a royal pain, but possible, I think.
Anthony, please hold off on merging
https://sourceware.org/ml/libffi-discuss/2013/msg00218.html which has
even worse backwards compatibility issues with cif->abi values.
--
Alan Modra
Australia Development Lab, IBM