[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