UnmanagedCallersOnlyAttribute does not properly export mangled names to aot DLL when using stdcall on x86 windows

[tyrel-alastair-hunter-bosch]

Describe the bug

When using UnmanagedCallersOnlyAttribute to export a function into a native library on x86 platforms if the function uses stdcall then the name is not properly mangled.

To Reproduce

internal static class NameMangling
{
    [UnmanagedCallersOnly(EntryPoint = "TestNameMangling", CallConvs = new Type[] { typeof(CallConvStdcall) })]
    public static unsafe int TestNameMangling(void* name, int* id)
    {
        return 0;
    }

 <PropertyGroup>
   <TargetFramework>net10.0</TargetFramework>
   <OutputType>Library</OutputType>
   <PublishAot>true</PublishAot>
   <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
   <StripSymbols>true</StripSymbols>
 </PropertyGroup>

Further technical details

Its expected that when publishing with dotnet publish -r win-x86 --self-contained
then using dependencies gui to inspect the published dll that you should see both

TestNameMangling exported
as well
as _TestNameMangling@8 exported.
Without this export any native assembly that load this assembly at runtime will have issues with loading this function pointer.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[jkotas]

TestNameMangling exported as well as _TestNameMangling@8 exported.

Why would you expect both to be exported? I would expect this to work in the exact same way as the following C/C++:

extern "C" __declspec(dllexport) int __stdcall TestNameMangling(void* name, int* id)
{
    return 0;
}

It only exports one.

cc @filipnavara

[filipnavara]

My expectation is that DLLs export (only) unmangled symbols regardless of calling convention. That's how Windows DLLs are produced and how NativeAOT behaves (AFAIK).

We don't have a concise story of producing import library or .def files to solve the consumption side of the build. We may also not do the right thing for static libraries but that's only semi-supported advanced scenario.

[jkotas]

My expectation is that DLLs export (only) unmangled symbols regardless of calling convention. That's how Windows DLLs are produced

It depends on how you produce the Windows DLL. If you use __declspec(dllexport) without .def file, the C++ toolset will export the mangled name. For example, the exported entrypoint for my C/C++ snippet above is _TestNameMangling@8.

However, many Windows DLL have .def files and override the export to have non-mangled name. It is how NativeAOT works currently. The exported entrypoint for the C# snippet above is TestNameMangling.

[tyrel-alastair-hunter-bosch]

We currently have a C++ library that __declspec(dllexport) without .def file and this exports _TestNameMangling@8 we have a requirement from a specification that these names must be mangled and we would like to move to a c# AOT however cannot get the names to be produced with mangling even if we modify the def file after generating native code but before linking

[tyrel-alastair-hunter-bosch]

Also we need to be able to control the ordinal as well for the exported function.

[tyrel-alastair-hunter-bosch]

This is a generic abstraction of the specification of the .def file that we need to be able to produce.

MYDLL.DEF: Declares the module parameters.
LIBRARY “MYDLL.DLL”
EXPORTS
FUNC1 @1 PRIVATE
FUNC2 @2 PRIVATE
FUNC3 @3 PRIVATE
FUNC4 @4 PRIVATE
FUNC5 @5 PRIVATE
FUNC6 @7 PRIVATE
The DLL shall not export any functions or variables other than those listed above. NOTE: The ordinal number 6 was used for a now obsolete API function and shall not be used.