Closed kennykerr closed 1 year ago
@tannergooding Can you confirm ClangSharp doesn't have the ability to set a default calling convention? It seems you can either choose to remap everything and lose all calling convention attribute output (--with-callconv *=Winapi
) or choose to remap nothing and ClangSharp defaults to Cdecl.
Think we need a --default-callconv
to override the defaults in ClangSharp?
Maybe there’s an option we can give to clang. Unfortunately I’m out of town until Sunday so I can’t try it until then.
@sotteson1 Good idea, will look now.
I changed base settings for all archs as follows:
--additional -mrtd
...--with-callconv *=stdcall
--with-callconv *=stdcall
With the hopes that x64/arm64 passes would simply drop the calling convention (but after grouping them during cross-arch operations since I mapped them all to stdcall). But this resulted in all the functions getting marked stdcall again regardless of architecture. I think there's some additional work needed to make this all work on our side.
No fast fix here, see you Sunday/Monday.
The actual issue here is that Clang doesn't surface any calling convention information for x64
(outside vectorcall
and varargs
) because there isn't any other convention. As far as x64 windows
is concerned, cdecl == stdcall == fastcall
.
For 32-bit this matters, but Clang only surfaces that when the file was processed for -m32
(rather than -m64
). There are some downside of processing as -m32
as well, such as various other defines/definitions being incorrect in certain edge cases.
However, processing as both -m32
and -m64
to observe the differences and then manually specify --with-callconv name=cdecl
in the few places that aren't stdcall
and to catch any structs where the layout is truly different between 32-bit/64-bit might be a good idea anyways.
I know one example where the 32-bit vs 64-bit layouts are incompatible is um/commctrl.h
for TBBUTTON
. IIRC there were others in setupapi
and a couple other headers as well.
We scan multiple times for x86 (using -m32) and x64/arm64 (using -m64), although if we previously detected they were all equivalent for a partition (a set of headers) we only scan once using x64. So maybe to detect calling convention, we need to scan the “common” ones using x86 (-m32). Would that get us the information we need?
That should. Clang supports (and has tests) covering that the default calling convention detection works as expected for -m32
.
Having a --with-callconv *=stdcall
will prevent that from working, however. I could probably add something that reports a warning/error if targeting 32-bit and the override doesn't match -or- some special switch to state the default should be x
without overriding other cases. Would need to double check on the latter case, however, as I think "default" reports as cdecl
for x64 Windows.
There are a lot more now cdecl that aren't in the real DLLs (probably incomplete list):
Originally posted by @glandium in https://github.com/microsoft/windows-rs/issues/1999#issuecomment-1234848804