You are not logged in.
- Topics: Active | Unanswered
#1 2026-09-16 09:03:30
Three remaining ABI mismatches (Currency, QuickJS, size_t)
hi @ab, I am working on tauri-like project and found again ABI issues, I rechecked on current mormot2 commit 5f5bd05 (an hour ago).
[/AI 
]
The following three ABI/signature mismatches exists. They are independent, but I am grouping them here because they all concern calling conventions or C/Pascal boundaries. Detailed reports and reproductions are linked below.
1. Currency interface results remain incorrect on SysV x64 and AArch64
Commit 790154af correctly fixed Win64 by retaining the Currency result read from RAX. However, the same ABIX64 block is also used by SysV x64.
The hosted result matrix is:
Windows x86-64: 5 / 5
Linux x86-64: 1 / 5
macOS x86-64: 1 / 5
macOS AArch64: 0 / 5On SysV x64, only the zero-argument method succeeds. Methods with arguments return pointer-shaped values from RAX. The previous XMM0 path did not work either, so merely restoring the former branch would not be a safe correction.
AArch64 still explicitly stores D0 for imvCurrency, but all five measured return cases fail there.
This is not a SysV regression introduced by 790154af: Currency results were already wrong before it. That commit fixed Win64 while leaving the other ABIs unresolved.
Detailed report and reproduction: mormot-imvcurrency-rax-sysv-x64.md
Suggested direction: separate the result handling by ABI and add the five-method Currency matrix to the cross-platform tests. The SysV compiler-generated convention probably needs to be measured before choosing RAX, XMM0, or a hidden result location.
2. JS_SetMaxStackSize takes the wrong opaque pointer type
The Pascal binding still declares:
procedure JS_SetMaxStackSize(ctx: JSContext; stack_size: PtrUInt);The QuickJS header shipped in the same repository declares:
void JS_SetMaxStackSize(JSRuntime *rt, size_t stack_size);Passing a JSContext where QuickJS expects a JSRuntime makes the C function write the stack limit at a runtime-relative offset inside the context object. This was reproduced as an access violation under allocation pressure. Using an otherwise identical declaration with JSRuntime is stable.
The mechanical correction appears to be:
procedure JS_SetMaxStackSize(rt: JSRuntime; stack_size: PtrUInt);
cdecl; external {$ifdef QJSDLL}QJ{$endif};Detailed report: mormot-quickjs-js-setmaxstacksize-signature.md
3. pas_malloc and pas_malloc_usable_size still truncate size_t on 64-bit targets
The current Pascal exports include:
function pas_malloc(size: cardinal): pointer; cdecl;
function pas_malloc_usable_size(P: pointer): integer; cdecl;The patched QuickJS C header calls them as:
void *pas_malloc(size_t size);
size_t pas_malloc_usable_size(void *ptr);On a 64-bit target, a request above 4 GiB is therefore truncated to its low 32 bits. The allocation may succeed with a much smaller buffer than the C caller requested.
This seems related to issue #324, but the correction made for that issue widened pas_realloc and several libc declarations while leaving pas_malloc and pas_malloc_usable_size unchanged.
Suggested ABI types:
function pas_malloc(size: PtrUInt): pointer; cdecl;
function pas_realloc(P: pointer; size: PtrUInt): pointer; cdecl;
function pas_malloc_usable_size(P: pointer): PtrUInt; cdecl;pas_calloc should use pointer-sized unsigned operands and reject multiplication overflow. The Delphi-local allocator implementations in mormot.lib.quickjs.pas should also be audited because they still use 32-bit sizes and a four-byte stored-size prefix.
Detailed report: mormot-static-pas-malloc-size-t.md
[/AI]
The repo made last month (mormot-fpc-win64-callmethod-unwind) is currently being updated, with patches and added tests that could be included on the framework tests. I'll post to confirm. I thought you might want to take a look since you're working on the assembly code as I write this 
- thread ref: https://synopse.info/forum/viewtopic.php?id=4418
Last edited by flydev (2026-09-16 09:05:02)
Offline
#2 2026-09-16 10:15:10
Re: Three remaining ABI mismatches (Currency, QuickJS, size_t)
The run/tests are green and the patch file is there: mormot2-2026-09-16-abi-fixes.patch
if everything make sense, I can send a PR if you want.
edit 2: mormot2 regression suite is missing after patch test to really confirm, they should be ran on every platform, I will add them this afternoon.
Last edited by flydev (2026-09-16 10:34:15)
Offline
#3 2026-09-16 11:18:38
Re: Three remaining ABI mismatches (Currency, QuickJS, size_t)
I have fixed currency result in mormot.core.interfaces, but on FPCPOSIX it returns it into FP0 not XMM0 as proposed.
https://github.com/synopse/mORMot2/commit/6a27c07fc6c9
See also https://github.com/synopse/mORMot2/commit/37fa86b45
and https://github.com/synopse/mORMot2/commit/66d7d51c1
Thanks for the feedback!
Offline