-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
There are many APIs that are exported as stdcall
but are now declared to be cdecl
#1217
Comments
@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 ( Think we need a |
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:
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 For 32-bit this matters, but Clang only surfaces that when the file was processed for However, processing as both I know one example where the 32-bit vs 64-bit layouts are incompatible is |
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 Having a |
There are a lot more now cdecl that aren't in the real DLLs (probably incomplete list):
Originally posted by @glandium in microsoft/windows-rs#1999 (comment)
The text was updated successfully, but these errors were encountered: