src/coreclr/vm/qcallentrypoints.cpp:320 memset problem

[gwr]

Description

After a rebase past the fix for #122791, compilation fails with cross-build for illumos (cross-gcc 13.3.0):

  /ws/dotnet/runtime/src/native/minipal/entrypoints.h:19:20: error: address of overloaded function with no contextual type information
     19 |     {#impl, (void*)&impl},
  /ws/dotnet/runtime/src/coreclr/vm/qcallentrypoints.cpp:320:5: note: in expansion of macro 'DllImportEntry'
    320 |     DllImportEntry(memset)

Reproduction Steps

export CMAKE_MAKE_PROGRAM=/usr/local/bin/cmake
export ROOTFS_DIR=/ws/dotnet/crossrootfs/x64

./build.sh clr+libs+packs -c Debug -gcc --keepnativesymbols true -cross -os illumos "$@"

Expected behavior

Build succeeded.
    0 Warning(s)
    0 Error(s)

Actual behavior

  Failed to build "CoreCLR component".
/ws/dotnet/runtime/src/coreclr/runtime.proj(116,5): error MSB3073: The command ""/ws/dotnet/runtime/src/coreclr/build-runtime.sh" -x64 -debug gcc -cross -keepnativesymbols -os illumos -targetrid illumos-x64 -cmakeargs "-DCLR_DOTNET_RID=illumos-x64" -cmakeargs "-DCLR_DOTNET_HOST_PATH=/ws/dotnet/runtime/.dotnet/dotnet" -cmakeargs "-DCDAC_BUILD_TOOL_BINARY_PATH=/ws/dotnet/runtime/artifacts/bin/coreclr/illumos.x64.Debug/cdac-build-tool/cdac-build-tool.dll" -cmakeargs "-DCLR_CMAKE_RUNTIME_CORECLR=1" -cmakeargs "-DCMAKE_PRODUCT_VERSION=11.0.0" -cmakeargs "-DCMAKE_CONTINUOUS_INTEGRATION_BUILD=false" -cmakeargs "-DCMAKE_NET_CORE_APP_CURRENT_VERSION=11.0" -cmakeargs "-DCMAKE_BUILD_LIBRARIES_CONFIGURATION=Debug" -cmakeargs "-DCMAKE_BUILD_RUNTIME_CONFIGURATION=Debug"" exited with code 2.

Build FAILED.

Regression?

The problem started after this commit:

From d9533874e832dde83c72be3e10da91e0b81b0826 Mon Sep 17 00:00:00 2001
From: Copilot <198982749+Copilot@users.noreply.github.com>
Date: Fri, 2 Jan 2026 06:57:25 -0800
Subject: [PATCH] Consolidate runtime helpers (X86Base, Interlocked, Buffer)
 across NativeAOT and non-NativeAOT (#122791)

Shared implementations of few QCalls across NativeAOT and non-NativeAOT.

I'm not sure why memset lacks context information in this build.
It appears that <string.h> has been included.
If the symbol reference is changed to std::memset that works.
@jkotas added #122791 -- any ideas why this failed?
Thanks -gwr

Known Workarounds

This patch lets the code build for me.

diff --git a/src/coreclr/vm/qcallentrypoints.cpp b/src/coreclr/vm/qcallentrypoints.cpp
index de9009ad992..5263965be94 100644
--- a/src/coreclr/vm/qcallentrypoints.cpp
+++ b/src/coreclr/vm/qcallentrypoints.cpp
@@ -317,7 +317,9 @@ static const Entry s_QCall[] =
 #endif // FEATURE_COMINTEROP
     DllImportEntry(Monitor_GetOrCreateLockObject)
     DllImportEntry(ClrConfig_GetConfigBoolValue)
-    DllImportEntry(memset)
+    // DllImportEntry(memset) // error:
+    // address of overloaded function with no contextual type information
+    {"memset", (void*)&std::memset},
     DllImportEntry(memmove)
     DllImportEntry(DependentHandle_InternalAllocWithGCTransition)
     DllImportEntry(DependentHandle_InternalFreeWithGCTransition)

Configuration

My dotnet branch HEAD is 420d1ef

Build host is:
$ uname -a
Linux rock-ubuntu 6.8.0-90-generic #91-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 18 14:14:30 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Target is illumos-x64

Determining projects to restore...
Tool 'coverlet.console' (version '6.0.4') was restored. Available commands: coverlet
Tool 'dotnet-reportgenerator-globaltool' (version '5.4.3') was restored. Available commands: reportgenerator
Tool 'microsoft.dotnet.xharness.cli' (version '11.0.0-prerelease.26058.2') was restored. Available commands: xharness
Tool 'microsoft.visualstudio.slngen.tool' (version '12.0.15') was restored. Available commands: slngen

I'm not sure if this error occurs with any other targets.

Other information

No response

[jkotas]

{"memset", (void*)&std::memset},

std::memset looks like a wrapper over C memset. I suspect that it will come with extra overhead. We do not want that.

Would it be possible to change the definition DllImportEntry macro to:

#define DllImportEntry(impl) \
    {#impl, (void*)&::impl},

so that it avoids C++ cruft?

I am wondering why we do not see it on other platforms. What's special about illumos that it hits this problem?

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[gwr]

I'm not sure why this happens. Maybe there's more than one memset() declaration exposed in this compilation, but I'm not sure how to track that down. I tried this:

    {"memset", (void*)&::memset},

but that fails the same as the original:

  /ws/dotnet/runtime/src/coreclr/vm/qcallentrypoints.cpp:322:23: error: address of overloaded function with no contextual type information
    322 |     {"memset", (void*)&::memset},

So given that std::memset builds OK, I guess this may be some sort of header incompatibility that's somehow exposed here? Not sure. Suggestions welcome.
From what I read, using the std::name form is recommended for portability.
That's just being explicit about the name space: "I want the standard one".
There's no costly wrapper involved here.

I tried making a minimal test case to demonstrate this, but this builds fine on the platform using the same g++ 13.3.0

#include <string.h>

typedef struct
{
    const char* name;
    const void* method;
} Entry;

const Entry s_QCall[] =
{
     {"memset",  (void*)&memset},
     {"memmove", (void*)&memmove},
};

That makes me think this is somehow caused by pulling in some headers that may not be expected to go together. (Just a guess).

[gwr]

Is there a convenient way to get the coreclr build to run "g++ -E" and save the C pre-processor (cpp) output so I can see exactly what we end up with from all those includes?
A: Found: artifacts/obj/coreclr/illumos.x64.Debug/compile_commands.jso

So then the qcallentrypoints.cpp.i (intermediate CPP output)
compiles just fine with g++ so something else is unhappy.
I need to see the real details of what the build is doing here.

[am11]

This patch lets the code build for me.

Or simply

-    DllImportEntry(memset)
+    DllImportEntry(std::memset)

I am wondering why we do not see it on other platforms. What's special about illumos that it hits this problem?

illumos headers have using namespace std; etc. which were giving hard time cross compiling with clang as we do on FreeBSD and other platforms (fix one issue, ten others will crop up). There was some hope from libc++ but then they completely dropped the support in https://reviews.llvm.org/D138680 (reason: dead platform). Therefore libstdc++ is the only way rn with all kinds of hacks in C++ header files.