[PATCH] D116020: [clang][#52782] Bail on incomplete parameter type in stdcall name mangling
Markus Böck via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Jan 3 15:31:55 PST 2022
zero9178 added a comment.
In D116020#3218453 <https://reviews.llvm.org/D116020#3218453>, @majnemer wrote:
> I wonder if we should have different behavior for MSVC targets.
>
> If I do:
>
> class Incomplete;
> extern "C" int __stdcall Fn(int, Incomplete, long long);
> auto fnptr = &Fn;
>
> MSVC generates:
>
> EXTRN _Fn at 12:PROC
>
> It appears that they skip over incomplete types.
>
> Should the behavior for incomplete types depend on the target?
That's actually a good point! I originally failed to get MSVC to generate a symbol for just the function declaration and thought it might just be irrelevant for MSVC. I didn't think of just using the function as you did lol. In the case of MinGW it always gets through the mangled as debug info is generated for the whole class, including just the method declaration.
I experimented a bit with your code and found a few interesting things:
clang actually refuses taking the address of a stdcall function if it has an incomplete type parameter:
clang-cl test.cpp test2.cpp --target=i686-pc-windows-msvc
test.cpp(3,15): error: parameter '' must have a complete type to use function 'Fn' with the stdcall calling convention
auto fnptr = &Fn;
^
test.cpp(1,7): note: forward declaration of 'Incomplete'
class Incomplete;
^
1 error generated.
Meanwhile cl will compile but fail to link with another object file that calls `fnptr`:
test.obj : error LNK2001: unresolved external symbol _Fn at 12
Hint on symbols that are defined and could potentially match:
_Fn at 16
test.exe : fatal error LNK1120: 1 unresolved externals
As both of them error out one way I am guessing it simply doesn't matter how the incomplete stdcall gets mangled. One cannot create calls to the function while the parameter type is incomplete and therefore no references to it are created.
How DWARF debuggers handle the "wrong" declarations in the debug info I have no clue about however. Given that GCC works the same however I am guessing gdb handles it correctly.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D116020/new/
https://reviews.llvm.org/D116020
More information about the cfe-commits
mailing list