* refactor(ci): improve wget retry logic in .ci/install.sh
* build(github-actions): use static runtime library in build
* refactor(ffi.h.in): export version API
* chore: update libffi version to 3.5.0-rc1
Closures on powerpc64-linux using static trampolines do not work when
statically linking libffi. The problem is the usage of tramp_globals.text
in libffi assumes it contains the entry point address of the first trampoline.
Powerpc's ffi_tramp_arch code returns &trampoline_code_table which for ABIs
that use function descriptors, ends up returning trampoline_code_table's
function descriptor address instead of its entry point address. Update
the code to always return the entry point address for all ABIs.
Similarly to f515eac04cf8e5f594d5d9dee5fb7dfc3a186a4c, add a .note.GNU-stack
marker to pa/linux.S as it doesn't need an executable stack. Absence of the
note means that GNU Binutils will consider it as needing an executable stack
and mark it as such automatically.
When building libffi on HPPA with `-Wl,--warn-warn-execstack`, we get:
```
ld: warning: src/pa/.libs/linux.o: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
```
That becomes more problematic with glibc-2.41 which forbids dlopen()
of a library with an executable stack, and libffi is commonly dlopen()'d,
especially by Python.
I suspect the reason it didn't show up on Debian is that since February,
Debian has been building Binutils with --disable-default-execstack.
Bug: https://bugs.gentoo.org/953805
Bug: https://github.com/libffi/libffi/issues/898
Add static trampoline support to all three powerpc Linux ABIs, specifically
powerpc-linux (32-bit SYSV BE), powerpc64-linux (64-bit ELFv1 BE) and
powerpc64le-linux (64-bit ELFv2 LE). This follows the s390x implementation
and does not introduce a ffi_closure_*_alt function, but rather jumps
directly to the ffi_closure_* function itself. If compiling with
--with-gcc-arch=power10 and pc-relative is enabled, we use a simpler and
smaller trampoline that utilizes Power10's new pc-relative load instructions.
I accidentally omitted the "ABI_ATTR" attribute, so that the testsuite
fails when testing the Microsoft ABI.
Fixes: fe203ffbb2bd ("Fix bugs in the x86-64 and x32 target (#887) (#889)")
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
This commit fixes two bugs in ffi in the x86-64 target. The bugs were
introduced by the commit d21881f55ed4a44d464c9091871e69b0bb47611a ("Fix
x86/ffi64 calls with 6 gp and some sse registers").
The first bug is that when we pass an argument with less than 8 bytes,
ffi will read memory beyond argument end, causing a crash if the argument
is located just before the end of the mapped region.
The second bug is in the x32 ABI - pointers in x32 are 4-byte, but GCC
assumes that the pointer values in the registers are zero-extended. ffi
doesn't respect this assumption, causing crashes in the called library.
For example, when we compile this function for x32:
int fn(int *a)
{
if (a)
return *a;
return -1;
}
we get this code:
fn:
testq %rdi, %rdi
je .L3
movl (%edi), %eax
ret
.L3:
movl $-1, %eax
ret
When we call this function using ffi with the argument NULL, the function
crashes because top 4 bytes of the RDI register are not cleared.
Fixes: d21881f55ed4 ("Fix x86/ffi64 calls with 6 gp and some sse registers (#848)")
Signed-off-by: Mikulas Patocka <mikulas@twibright.com>
While PAC was enabled, the bit to indicate support in the GNU Notes
section of the ELF was missing.
Before:
readelf -n ./aarch64-unknown-linux-gnu/.libs/libffi.so
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI
This was caused by this file not having PAC indicated in GNU Notes and
the linker discarding it:
File: ./aarch64-unknown-linux-gnu/src/aarch64/sysv.o
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI
Now it has it:
File: ./aarch64-unknown-linux-gnu/src/aarch64/sysv.o
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC
As well as the output shared object:
readelf -n ./aarch64-unknown-linux-gnu/.libs/libffi.so
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: AArch64 feature: BTI, PAC
Fixes: #881
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* Emscripten: cleanup
* Emscripten: remove support for `-sWASM_BIGINT=0`
* Emscripten: remove redundant CircleCI config
* Emscripten: modernize CI
* Ensure test helper methods are static
Similar to #644.
* Fix test failures in `cls_multi_{s,u}shortchar`
To build ELF shared libraries that do not require executable stack on
MIPS, every object file linked should have a .note.GNU-stack section,
otherwise the linker defaults to executable stack.
As libffi shouldn't require executable stack, add the .note.GNU-stack
section to the assembly source files under src/mips, like other
architectures.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
In the C23 revision of the C standard, `va_start` ignores its second
argument, which is no longer required (previously the last named
function parameter - which the compiler knows anyway, so it's
redundant information).
This has the consequence for the libffi testsuite, when making GCC
default to `-std=gnu23`, of making two tests fail with warnings about
an unused function argument (only passed to `va_start` and not
otherwise used). Fix those test failures by explicitly casting the
argument to `void`.
This is a fix for https://github.com/libffi/libffi/issues/852: error: invalid CFI advance_loc expression on apple targets.
The CFI for darwin arm64 was broken because the CNAME macro was being used after the
cfi_startproc macro.
The pattern for several of the architectures is for ffi_call_int to
stack-allocate some arguments + the registers, and then
ffi_call_$ARCH will pop the top of that structure into registers, and
then adjust the stack pointer such that the alloca'd buffer _becomes_
the stack-passed arguments for the function being called.
If libffi is compiled with ASAN, then there will be a redzone inserted
after the alloca'd buffer which is marked as poisoned. This redzone
appears beyond the end of $sp upon entry to the called function.
If the called function does anything to use this stack memory, ASAN will
notice that it's poisoned and report an error.
This commit fixes the situation (on the architectures that I have access
to) disabling instrumentation for ffi_call_int; that means there will be
no alloca redzone left on the shadow-stack.
