* use rcedit to add metainfo to DLL
* remove trailing backslash in build.yml
* build.yml: add rcedit execute permission
* build.yml: cd to the right directory
* 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>
