[Sanitizers] [MinGW] Produce undecorated symbols for /export: directives when in MinGW mode

[mstorsjo]

Summary

In MinGW mode, the /export: directives in object files are interpreted differently; the symbols are not assumed to be decorated.

Since the GNU linker doesn't support the /alternatename and /include directives, there's no such distinction for them in lld. This assumes that the resulting sanitizer libraries will be linked by lld.

[mstorsjo]

@rnk - Any input on this issue? This shows the thing that really requires lld, and which kind of is "undefined" how it should behave in a mingw configuration, since ld.bfd doesn't support it.

[rnk]

I'm just waiting to hear from other sanitizer maintainers about their stance on adding the complexity of supporting mingw headers in the sanitizers.

[mstorsjo]

In D51882#1232432, @rnk wrote:

I'm just waiting to hear from other sanitizer maintainers about their stance on adding the complexity of supporting mingw headers in the sanitizers.

Ok. FWIW, these patches that are left are the only one necessary (as I've seen so far; it builds fine and runs fine for some simple testcases at least), so there's not an indeterminate long tail of other tweaks needed.

[eugenis]

So far the changes look fine to me.
Let's wait for @kcc, who hates ifdefs, to chime in.

[mstorsjo]

Ping @kcc (or others)

[rnk]

lgtm

compiler-rt/trunk/lib/sanitizer_common/sanitizer_win_defs.h

 #endif
 
 #if defined(_M_IX86) || defined(__i386__)
 #define WIN_SYM_PREFIX "_"
 #else
 #define WIN_SYM_PREFIX
 #endif
 
+// For MinGW, the /export: directives contain undecorated symbols, contrary to
+// link/lld-link. The GNU linker doesn't support /alternatename and /include
+// though, thus lld-link in MinGW mode interprets them in the same way as
+// in the default mode.
+#ifdef __MINGW32__
+#define WIN_EXPORT_PREFIX
+#else
+#define WIN_EXPORT_PREFIX WIN_SYM_PREFIX
+#endif
+
 // Intermediate macro to ensure the parameter is expanded before stringified.
 #define STRINGIFY_(A) #A
 #define STRINGIFY(A) STRINGIFY_(A)
 
 // ----------------- A workaround for the absence of weak symbols --------------
 // We don't have a direct equivalent of weak symbols when using MSVC, but we can
 // use the /alternatename directive to tell the linker to default a specific
 // symbol to a specific value.

 #define WIN_WEAK_ALIAS(Name, Default)                                          \
   __pragma(comment(linker, "/alternatename:" WIN_SYM_PREFIX STRINGIFY(Name) "="\
                                              WIN_SYM_PREFIX STRINGIFY(Default)))
 
 #define WIN_FORCE_LINK(Name)                                                   \
   __pragma(comment(linker, "/include:" WIN_SYM_PREFIX STRINGIFY(Name)))
 
 #define WIN_EXPORT(ExportedName, Name)                                         \
-  __pragma(comment(linker, "/export:" WIN_SYM_PREFIX STRINGIFY(ExportedName)   \
-                                  "=" WIN_SYM_PREFIX STRINGIFY(Name)))
+  __pragma(comment(linker, "/export:" WIN_EXPORT_PREFIX STRINGIFY(ExportedName)   \
+                                  "=" WIN_EXPORT_PREFIX STRINGIFY(Name)))
 
 // We cannot define weak functions on Windows, but we can use WIN_WEAK_ALIAS()
 // which defines an alias to a default implementation, and only works when
 // linking statically.
 // So, to define a weak function "fun", we define a default implementation with
 // a different name "fun__def" and we create a "weak alias" fun = fun__def.
 // Then, users can override it just defining "fun".
 // We impose "extern "C"" because otherwise WIN_WEAK_ALIAS() will fail because