On 5/12/2026 10:40 AM, Oliver Smith-Denny wrote:
On 5/12/2026 10:33 AM, Ard Biesheuvel wrote:
On Tue, 12 May 2026, at 19:10, Oliver Smith-Denny wrote:
On 5/12/2026 9:57 AM, Ard Biesheuvel via groups.io wrote:
If not, then I don't think this is fixable. If it does, then we need to
fix the VA_LIST definitions for _M_ARM64.
Yeah, I think the question is whether we should rely on the compiler
builtins here or use our own definitions here, the char * and related
macros.
Because this is AAPCS64 defined, I somewhat lean towards saying MSVC did
this wrong and we shouldn't punish the toolchains that did this right.
Unfortunately, that doesn't solve the problem.
We still could make sure CLANGPDB takes advantage of the compiler
builtins by avoiding the _M_ARM64 path, that presumably would have
some benefit, but again, doesn't solve this problem.
Agreed. No need to force Clang to do the wrong thing here.
I or someone on my team will put up a PR to address this (which again,
__builtin_va_list on CLANGPDB is still the MS ABI, so there might be
some perf benefit, but no interop benefit) and we'll fix up the in-tree
usage of VA_LIST across ABI boundaries (which may be limited to the
crypto case).
Sean had an idea I liked here: why not handroll the AAPCS64 ABI for
the VA* implementation in Base.h so that CLANGPDB can align to the spec
correctly and not have interop issues with GCC/CLANGDWARF? We would do
the same for MSVC ARM64, but again, I consider that to be a dead
toolchain.
The MS ABI code in Base.h is already handrolled because no compiler
builtin for MSVC exists.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121941): https://edk2.groups.io/g/devel/message/121941
Mute This Topic: https://groups.io/mt/119278849/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
