* Fix closures using FFI_REGISTER ABI
ffi_closure_REGISTER had the positions of the closure and return address
switched, resulting in a segfault when calling a closure created with
the FFI_REGISTER ABI.
* Fix comment and remove redundant assembly
* After fixing closures using FFI_REGISTER ABI, the comments were
incorrect, not reflecting the value that was actually loaded into eax
and ecx.
* Additionally, ecx was loaded with the data at esp + closure_FS only
to write it back to esp + closure_FS. Both commands were removed as
they end up not having any effect as ecx is overwritten during
FFI_CLOSURE_COPY_TRAMP_DATA.
The .arch directive is only relevant for ELF targets, it is
unsupported for COFF and MachO targets.
Before 170bab47c90626a33cd08f2169034600cfd9589c, this was
not an issue as the directive was filtered out by the
ifndef __clang__.
Add static trampoline support to riscv32 and riscv64 Linux ABIs.
The implementation follows the s390x and powerpc implementations
which does not introduce a ffi_closure_*_alt function, but rather
jumps directly to the ffi_closure_asm function itself.
* src/wasm32: Allow building with Emscripten with 64bit support
MEMORY64 enables 64bit pointers so this commit updates the accessors for the
libffi data structures accordingly.
Each JS functions in ffi.c receives pointers as BigInt (i64) values and with
casts them to Numer (i53) using bigintToI53Checked. While memory64 supports
64bit addressing, the maximum memory size is currently limited to 16GiB
[1]. Therefore, we can assume that the passed pointers are within the
Number's range.
[1] https://webassembly.github.io/memory64/js-api/#limits
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
* Add wasm64 target to the build scripts
This commit adds support for the wasm64 target via the configure
script. Emscripten supports two modes of the -sMEMORY64 flag[1] so the
script allows users specifying the value through a configuration variable.
Additionally, "src/wasm32" directory has been renamed to the more generic
"src/wasm" because it's now shared between both 32bit and 64bit builds.
[1] https://emscripten.org/docs/tools_reference/settings_reference.html#memory64
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
* GitHub Actions: Add wasm64 tests
This commit adds a test matrix for wasm32, wasm64 and wasm64 with the
-sMEMORY64=2 flag, using the latest version of Emscripten. -Wno-main is
added to suppress the following warning in unwindtest.cc and
unwindtest_ffi_call.cc.
> FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -O2 (test for excess errors)
> Excess errors:
> ./libffi.closures/unwindtest_ffi_call.cc:20:5: warning: 'main' should not be 'extern "C"' [-Wmain]
> 20 | int main (void)
> | ^
> 1 warning generated.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
* testsuite: Fix types of main function
test_libffi.py calls each test's main function without arguments, but some
tests define the main function with parameters. This signature mismatch
causes a runtime error with the recent version of Emscripten.
This commit resolves this issue by updating the function signatures to match
the way they are called.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
* README: Add document about WASM64
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
---------
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
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.
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>
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.
* arc: Fix warnings
These warnings are fixed:
1. A series of "unused variables".
2. Implicit conversion from a pointer to uint32_t.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
* arc: Do not use mov_s and movl_s instructions
mov_s and movl_s instructions use a restricted set of registers.
However, a list of available registers for such instructions for
one ARC target may not match a list for another ARC targets. For
example, it is applicable to ARC700 and ARC HS3x/4x - build
fails because mov_s formats may be incompatible in some cases.
The easiest and the most straightforward way to fix this issue
is to use mov and movl instead of mov_s and movl_s.
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
---------
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
* src/or1k/ffi.c: fix prototype of ffi_call_SYSV()
The current code base of libffi on OpenRISC (or1k) fails to build with
GCC 14.x with the following error:
../src/or1k/ffi.c: In function 'ffi_call':
../src/or1k/ffi.c:167:34: error: passing argument 3 of 'ffi_call_SYSV' from incompatible pointer type [-Wincompatible-pointer-types]
167 | ffi_call_SYSV(size, &ecif, ffi_prep_args, rvalue, fn, cif->flags);
| ^~~~~~~~~~~~~
| |
| void * (*)(char *, extended_cif *)
../src/or1k/ffi.c:113:27: note: expected 'void * (*)(int *, extended_cif *)' but argument is of type 'void * (*)(char *, extended_cif *)'
113 | void *(*)(int *, extended_cif *),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is due to the fact that ffi_prep_args() is in fact defined as:
void* ffi_prep_args(char *stack, extended_cif *ecif)
so, let's fix the prototype of the function pointer, which anyway gets
passed to assembly code, so the typing gets lost.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* src/or1k/ffi.c: fix incompatible pointer type
The current code base of libffi on OpenRISC (or1k) fails to build with
GCC 14.x with the following error:
../src/or1k/ffi.c: In function 'ffi_closure_SYSV':
../src/or1k/ffi.c:183:22: error: initialization of 'char *' from incompatible pointer type 'int *' [-Wincompatible-pointer-types]
183 | char *stack_args = sp;
| ^~
Indeed:
register int *sp __asm__ ("r17");
[..]
char *stack_args = sp;
Adopt the same logic used for:
char *ptr = (char *) register_args;
which consists in casting to the desired pointer type. Indeed, later
in the code stack_args is assigned to ptr (so they need to be the same
pointer type), and some arithmetic is done on ptr, so changing its
pointer type would change the behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---------
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is needed at least if building for Linux, with a toolchain
that doesn't default to having PAC enabled, fixing build errors
since 45d284f2d066cc3a080c5be88e51b4d934349797.
* aarch64: fix callstack in ffi_call_SYSV
The debug stack gets corrupted between the frame and stack pivots, update
the CFI directives so the call stack stays correct in the debugger.
str x9, [x1, #32] // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good)
mov x29, x1 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> ffi_call() -> main() (bad)
mov sp, x0 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good)
The CFA data needs to be updated around the pivots, after this patch the
callstack stays correct.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* aarch64: remove uneeded CFI directive
This directive doesn't actually set the CFA to anything valid, and
during unwinding this isn't even used. Note that the PAC/Darwin usage
is quite suspect as well, as the CFA is either x1 or x29 after the frame
pivot, and the CFA address is what's used as the modifier when verifying
the PAC. At least this is the behavior on Linux with PAC, I need to
verify ARME ABI unwinding. So for now leave Darwin as is.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* ptrauth: rename define for clarity
Rename the HAVE_PTRAUTH define for clarity that its associated with the
ARM64E ABI and not the ARM64 ABI that can be supported on Linux and
enabled with -mbranch-protection=standard.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* aarch64: add PAC support to ffi_call_SYSV
Support AARCH64 Pointer Authentication Codes (PAC) within ffi_call_SYSV
and support exception unwinding.
The Linux ABI for PAC is to use paciasp/autiasp instructions which also
have hint space equivelent instructions. They sign the LR (x30) with the
A key and the current stack pointer as the salt. Note that this can also be
configured to use the B key and will use pacibsp/autibsp hint instructions.
The Linux ABI for exception frame data when PAC is enabled assumes that the
Connonical Frame Address, or CFA is equal to the stack pointer. I.E sp is
equal to x29 (fp). When the unwinder is invoked the cfa will point to
the frame which will include the *signed* return address from the LR.
This will then be passed to __builtin_aarch64_autia1716 where the CFA
will be used as the salt and stored to register x16 and register x17
will contain the signed address to demangle. This can be noted in:
- d6d7afcdbc/libgcc/config/aarch64/aarch64-unwind.h (L56)
The other required portion of this is to indicate to the unwinder that
this is a signed address that needs to go the special demangle route in
the unwinder. This is accomplished by using CFI directive "cfi_window_save"
which marks that frame as being signed.
Putting all of this together is a bit tricky, as the internals of
ffi_call_SYSV the callee allocates its stack and frame and passes it in
arg1 (x0) and arg2 (x1) to the called function, where that function
pivots its stack, so care must be taken to get the sp == fp before
paciasp is called and also restore that state before autiasp is called.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---------
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* bti: add identifier to ffi_closure_SYSV_V_alt
This was missing BTI_C identifier.
Old Code:
ffi_closure_SYSV_V_alt:
0000fffff7f70500: ldr x17, [sp, #8]
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* testsuite: fix whitespace in Makefile.am
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
* aarch64: correct comment describing BTI
The comment is incorrect, BTI is enabled per mapping via mprotect with
PROT_BTI flag set, not per-process. When the loader loads the library,
if the GNU Notes section is missing this, PROT_BTI will not be enabled
for that mapping, but is independent of other mappings.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
---------
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
In N32 ABI, 8-bit or 16-bit integers should be extended following the
signedness of the integer, but 32-bit integers should always be
sign-extended to 64-bit (note that N32 ABI only works on 64-bit CPUs).
So handling this in everything using libffi would be nasty. And the
libffi code for architectures with a similar rule (LoongArch & RISC-V)
also properly handle this. Let's do this work in libffi for MIPS N32
too.
This fixes two failures in Python 3.12.1 ctypes test.
This arguably is a compensation for a Python ctypes bug / strange behavior
described here:
a16a9f978f/Modules/_ctypes/stgdict.c (L718-L779)
If a struct is larger than 16 bytes, Python does not bother to accurately report
its contents figuring that we don't need to know.
When a program is loaded and linked, the first ELF file that doesn't
declare that BTI is supported in the GNU NOTES section disables BTI
support.
Example:
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
Fixes: #823
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Fix the build error with GCC 14:
../src/loongarch64/ffi.c: In function 'ffi_prep_closure_loc':
../src/loongarch64/ffi.c:525:7: error: implicit declaration of
function 'ffi_tramp_set_parms' [-Wimplicit-function-declaration]
GNU binutils refuses to assemble the direct BTI instructions unless
the target architecture explicitly supports BTI, ending up with errors
such as
../src/aarch64/sysv.S: Assembler messages:
../src/aarch64/sysv.S:87: Error: selected processor does not support `bti c'
../src/aarch64/sysv.S:156: Error: selected processor does not support `bti j'
Building with -march=armv8.5-a fixes building this.
However, the BTI instructions assemble into hint instructions, that
are ignored by processors that don't implement them. Therefore it is
possible to assemble them for the baseline armv8.0-a target as well,
by replacing "bti j" with "hint #36", "bti c" with "hint #34" and
"bti jc" with "hint #38"; this assembles into the same instruction
bits.
* [powerpc][AIX] fix layout issues for nested struct types
On AIX under the default power alignment rules, the layout
of struct types which are nested inside other structs may
be different than the layout of those types on their own.
Specifically the first member double rules which would
apply an eight byte alignment if that type appears in the
first position of a struct:
1) apply recursively if the struct appear in the first member
of another struct
2) do not apply if that struct is itself a member of another struct
and not the first member.
The current implementation of the rules in libffi doesn't handle these
cases, causing a mismatch with the compiler and causing some crashes
we see when OpenJ9 is used with libffi on AIX.
This PR corrects this and adds some representative test cases.
* Fix code style
* Add a size check
* Add additional test
* Fix padding in internal structs
* Flip condition back to original form
* Add a comment
* Add support for ARC and ARC64
Add support for ARC/ARC32/ARC64
* Implementation of GO Closure for ARC/ARC32/ARC64 Architectures
---------
Co-authored-by: Nuno Cardoso <cardoso@synopsys.com>
Co-authored-by: Luis Silva <luiss@synopsys.com>
* added build script
* Apply libffi-emscripten patch
* Some changes to wasm32/ffi.c
* Remove exit(0); from test suites
* Fix LONGDOUBLE argument type
* Use more macros in ffi.c
* Use switch statements instead of if chains
* Implemented struct args
* Finish struct implementation
* Partially working closures
* Got closures working (most of closures test suite passes)
* Revert changes to test suite
* Update .gitignore
* Apply code formatter
* Use stackSave and stackRestore rather than directly adjusting stack pointer
* Add missing break
* Fix visibility of ffi_closure_alloc and ffi_closure_free
* Fix FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used
sig needs to be vi here for FFI_TYPE_STRUCT and FFI_TYPE_LONGDOUBLE, noticed this while running the test suite without WASM_BIGINT support.
* Always use dynCall rather than direct wasmTable lookup (function pointer cast emulation changes dynCall)
* Prevent closures.c from duplicating symbols
* Try to set up CI
* Add test with bigint
* Make test methods static
* Remove BigInt shorthand because it messes up terser
* Add selenium tests
* Update tests a bit to try to make CI work
* WASM_BIGINT is a linker flag not a compile flag
* Finish getting CI working (#1)
* update gitignore
* Avoid adding "use strict;" to generated JS
This should be controlled by -s STRICT_JS in Emscripten.
* Make JavaScript ES5 compliant
* Remove redundant EXPORTED_RUNTIME_METHODS settings
* Fix definition of DEREF_I16
* Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used
* Add missing FFI_TYPE_STRUCT signature
* Improve test scripts
* Remove redundant EXPORTED_RUNTIME_METHODS settings
* Add missing EOL
* Add struct unpacking tests
* Update ci config to try to actually use WASM_BIGINT
* Revert "Avoid marshalling FFI_TYPE_LONGDOUBLE when WASM_BIGINT is not used"
This reverts commit 61bd5a3e20891623715604581b6e872ab3dfab80.
* Fix single_entry_structs tests
* Fix return from closure call
* Fix 64 bit return from closures
* only allocate as much space on stack for return pointer as needed
* Revert "only allocate as much space on stack for return pointer as needed"
This reverts commit e54a30faea3803e7ac33eed191bde9e573850fc1.
* xfail two tests
* Fix err_bad_abi test
* Remove test logging junk
* Try to set up long double marshalling for closures
* xfail err_bad_abi
* Fix reference errors in previous commit
* Add missing argument pointer assignment
* Fix signature of function pointer in cls_dbls_struct
* Fix longdouble argument
* Try some changes to bigint handling
* Fix BigInt handling
* Fix cls_longdouble test
* Fix long double closure arg with no WASM_BIGINT
* Use EM_JS to factor out js helpers
* Support for varargs closure calls
* Fix varargs calls
* Fix err_bad_abi test
* Fix typo in previous commit
* Add more assertions to closures test suite
* Fix some asserts
* Add assertions to a few more tests
* Fix some tests
* Fix more floating point assertions
* Update more tests
* Var args for ffi_call
* Don't do node tests
* Macro for allocating on stack
* Add some comments, simplify struct handling
* Try again to fix varargs calls, add comments
* Consolidate WASM_BIGINT conditionals into LOAD_U64 and STORE_U64 macros
* A bit of cleanup
* Fix another typo
* Some fixes to the testsuite
* Another testsuite fix
* Fix varags with closures?
* Another attempt at getting closure varargs to work
* sig is initialized later
* Allow libffi.closures tests to be run
* Improve build script
* Remove redundant semicolons
* Fix a few libffi.closures test failures
* Cleanup
* Legacy dynCall API is no longer used
* Fix FFI_TYPE_LONGDOUBLE offset
* xfail 2 tests for WASM
- closure_loc_fn0; not applicable -- codeloc doesn't point to closure.
- huge_struct; function signature too long.
* Revert some redundant dg-output/printf statements
Helps Node.
* Revert "Don't do node tests"
This reverts commit a341ef4b.
* Fix assertions in cls_24byte
* More tiny formating fixes to test suite
* Revert "Revert "Don't do node tests""
This reverts commit 7722e685ea04e2420e042886816d8c4dd31f5dcb.
* Fix 64 bit returns when WASM_BIGINT is absent
* Fix print statement in cls_24byte
* Add CALL_FUNC_PTR macro to allow pyodide to define custom calling behavior to handle fpcast
* Update single_entry_structs tests
* More explanations
* Fix compile error in last commit
* Add more support for pyodide fpcast emulation, update CI to try to test it
* Clone via https
* Fix path to pyodide emsdk_env
* Add asserts to the rest of the test suite
* Fix test compile errors
* Fix some tests
* Fix cls_ulonglong
* Fix alignment of <4 byte args
* fix cls_ulonglong again
* Use snprintf instead of sprintf
* Should assert than strncmp returned 0
* Fix va_struct1 and va_struct3
* Change double and long double tests
These tests are failing because of a strange bug with prinft and doubles, but I am not convinced
it necessarily has anything to do with libffi. This version casts the double to int before printing it and avoids the issue
* Enable node tests
* Revert "Change double and long double tests"
This reverts commit 8f3ff89c6577dc99564181cd9974f2f1ba21f1e9.
* Fix PYODIDE_FPCAST flag
* add conftest.py back in
* Fix emcc error: setting `EXPORTED_FUNCTIONS` expects `<class 'list'>` but got `<class 'str'>`
See discussion on https://github.com/pyodide/pyodide/pull/1596
* Remove test.html
* Remove duplicate test file
* More changes from upstream
* Fix some whitespace
* Add some basic debug logging statements
* Reapply libffi.exp changes
* Don't build docs (#7)
Works around build issue makeinfo: command not found.
* Update long double alignment
Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting
from `ChangeLog.md`:
> The alignment of `long double`, which is a 128-bit floating-point
> value implemented in software, is reduced from 16 to 8. The lower
> alignment allows `max_align_t` to properly match the alignment we
> use for malloc, which is 8 (raising malloc's alignment to achieve
> correctness the other way would come with a performance regression).
> (#10072)
* Update long double alignment
Emscripten 2.0.26 reduces the aligmnet of long double to 8. Quoting
from `ChangeLog.md`:
> The alignment of `long double`, which is a 128-bit floating-point
> value implemented in software, is reduced from 16 to 8. The lower
> alignment allows `max_align_t` to properly match the alignment we
> use for malloc, which is 8 (raising malloc's alignment to achieve
> correctness the other way would come with a performance regression).
> (#10072)
* Improve error handling a bit (#8)
* Fix handling of signed arguments to ffi_call (#11)
* Fix struct argument handling in ffi_call (#10)
* Remove fpcast emulation tests
* Align the stack to MAX_ALIGN before making call (#12)
* Increase MAX_ARGS
* Cleanup (#14)
* Fix Closure compiler error with -sASSERTIONS=1 (#15)
* Remove function pointer cast emulation (#13)
This reverts commit 593b402 and cbc54da, as it's no longer needed
after PR pyodide/pyodide#2019.
* Prefer the `__EMSCRIPTEN__` definition over `EMSCRIPTEN` (#18)
"The preprocessor define EMSCRIPTEN is deprecated. Don't pass it to code
in strict mode. Code should use the define __EMSCRIPTEN__ instead."
84a634167a/emcc.py (L887-L890)
* Install autoconf 2.71
* Try again with installing autoconf 2.71
* Fix compatibility with Emscripten 3.1.28
* CI: remove use of `EM_CONFIG` env
See commit:
3d87d5ea81
* Fix cls_multi_schar: cast rest_call to signed char
* Remove test xfails (#17)
* Fix long double when used as a varargs argument
* Enable unwindtest and fix it
* Add EM_JS_DEPS
* Also require convertJsFunctionToWasm
* Run tests very very verbose
* Echo the .emscripten file
* Remove --experimental-wasm-bigint insertion
* Build with assertions
* Move verbosity flags back out of LDFLAGS
* Remove debug print statement
* Use up to date pyodide docker image
* Explicitly cast res_call to fix test failure
* Put back name of main function in cls_longdouble_va.c
* Fix alignment
The stack pointer apparently needs to be aligned to 16. There were
some terrible subtle bugs caused by not respecting this. stackAlloc
knows that the stack should be 16 aligned, so we can use stackAlloc(0)
to enforce this. This way if alignment requirements change, as long
as Emscripten updates stackAlloc to continue to enforce them we should
be okay.
* Fix handling of systems with no Js bigint integration
When we run the node tests we use node v14 tests (since node v14 is
vendored with Emscripten). Node v14 has no Js bigint integration
unless the --experimental-wasm-bigint flag is passed. So only the
node tests really notice if we get this right. Turns out, it didn't
work. We can't call a JavaScript function with 64 bit integer arguments
without bigint integration.
In ffi_call, we are trying to call a wasm function that takes 64 bit
integer arguments. dynCall is designed to do this. We need to go back
to tracking the signature when we don't have WASM_BIGINT, and then use
dynCall. This works better now that emscripten can dynamically fill in
extra dynCall wrappers:
https://github.com/emscripten-core/emscripten/pull/17328
On the other hand, for the closures we are not getting a function pointer
as a first argument. We need to make our own wasm legalizer adaptor that
splits 64 bit integer arguments and then calls the JavaScript trampoline,
then the JavaScript trampoline reassembles them, calls the closure, then
splits the result (if it's a 64 bit integer) and the adaptor puts it back
together.
* Improvements to emscripten test shell scripts (#21)
This fixes the C++ unwinding tests and makes other minor improvements
to the Emscripten test shell scripts.
* Rename the test folder and move test files into emscripten test folder
* Use docker image that has autoconf-2.71
* Cleanup
* Pin emscripten 3.1.30
* Fix build.sh path
* Rearrange ci pipeline
* Fix bpo_38748 test
* Cleanup
* Improvements to comments, add static asserts, and update copyright
* Use `*_js` instead of `*_helper` for EM_JS functions (#22)
* Minor code simplification
* Xfail first dejagnu test to work around emscripten cache messages
See https://github.com/emscripten-core/emscripten/issues/18607
* Remove unneeded xfails
* Shorten conftest.py by using pytest-pyodide
* Apply formatters and linters to emscripten directory
* Fix Emscripten xfail hack
* Fix build-tests script
* Patch emscripten to quiet info messages
* Clean up compiler flags in scripts and remove some settings from circleci config
* Rename emscripten quiet script
* Add missing export
* Don't remove go.exp
* Add reference to emscripten logging issue
---------
Co-authored-by: Kleis Auke Wolthuizen <info@kleisauke.nl>
Co-authored-by: Kleis Auke Wolthuizen <github@kleisauke.nl>
Co-authored-by: Christian Heimes <christian@python.org>
It's defined in closures.c and used in tramp.c.
Also declare it as an hidden symbol, as it should be.
Co-authored-by: serge-sans-paille <sguelton@mozilla.com>
