[Support] Remove workarounds for building with mingw.org toolchains #145683
Conversation
Assume that mingw builds are made with mingw-w64 headers. The old mingw.org distribution isn't even accessible at the moment, and their project hosting site (osdn.net) seems to have been down for a couple of years, and their old project hosting (at sourceforge.net) hasn't been updated since 2018.
|
@llvm/pr-subscribers-platform-windows Author: Martin Storsjö (mstorsjo) ChangesAssume that mingw builds are made with mingw-w64 headers. The old mingw.org distribution isn't even accessible at the moment, and their project hosting site (osdn.net) seems to have been down for a couple of years, and their old project hosting (at sourceforge.net) hasn't been updated since 2018. Full diff: https://github.com/llvm/llvm-project/pull/145683.diff 1 Files Affected:
diff --git a/llvm/lib/Support/Windows/Signals.inc b/llvm/lib/Support/Windows/Signals.inc
index f11ad09f37139..959caa22f83ad 100644
--- a/llvm/lib/Support/Windows/Signals.inc
+++ b/llvm/lib/Support/Windows/Signals.inc
@@ -47,64 +47,6 @@
// back on at the end of the file.
#pragma GCC diagnostic ignored "-Wformat"
#pragma GCC diagnostic ignored "-Wformat-extra-args"
-
-#if !defined(__MINGW64_VERSION_MAJOR)
-// MinGW.org does not have updated support for the 64-bit versions of the
-// DebugHlp APIs. So we will have to load them manually. The structures and
-// method signatures were pulled from DbgHelp.h in the Windows Platform SDK,
-// and adjusted for brevity.
-typedef struct _IMAGEHLP_LINE64 {
- DWORD SizeOfStruct;
- PVOID Key;
- DWORD LineNumber;
- PCHAR FileName;
- DWORD64 Address;
-} IMAGEHLP_LINE64, *PIMAGEHLP_LINE64;
-
-typedef struct _IMAGEHLP_SYMBOL64 {
- DWORD SizeOfStruct;
- DWORD64 Address;
- DWORD Size;
- DWORD Flags;
- DWORD MaxNameLength;
- CHAR Name[1];
-} IMAGEHLP_SYMBOL64, *PIMAGEHLP_SYMBOL64;
-
-typedef struct _tagADDRESS64 {
- DWORD64 Offset;
- WORD Segment;
- ADDRESS_MODE Mode;
-} ADDRESS64, *LPADDRESS64;
-
-typedef struct _KDHELP64 {
- DWORD64 Thread;
- DWORD ThCallbackStack;
- DWORD ThCallbackBStore;
- DWORD NextCallback;
- DWORD FramePointer;
- DWORD64 KiCallUserMode;
- DWORD64 KeUserCallbackDispatcher;
- DWORD64 SystemRangeStart;
- DWORD64 KiUserExceptionDispatcher;
- DWORD64 StackBase;
- DWORD64 StackLimit;
- DWORD64 Reserved[5];
-} KDHELP64, *PKDHELP64;
-
-typedef struct _tagSTACKFRAME64 {
- ADDRESS64 AddrPC;
- ADDRESS64 AddrReturn;
- ADDRESS64 AddrFrame;
- ADDRESS64 AddrStack;
- ADDRESS64 AddrBStore;
- PVOID FuncTableEntry;
- DWORD64 Params[4];
- BOOL Far;
- BOOL Virtual;
- DWORD64 Reserved[3];
- KDHELP64 KdHelp;
-} STACKFRAME64, *LPSTACKFRAME64;
-#endif // !defined(__MINGW64_VERSION_MAJOR)
#endif // __MINGW32__
typedef BOOL(__stdcall *PREAD_PROCESS_MEMORY_ROUTINE64)(
@@ -536,12 +478,6 @@ void sys::PrintStackTraceOnErrorSignal(StringRef Argv0,
}
} // namespace llvm
-#if defined(__MINGW32__) && !defined(__MINGW64_VERSION_MAJOR)
-// Provide a prototype for RtlCaptureContext, mingw32 from mingw.org is
-// missing it but mingw-w64 has it.
-extern "C" VOID WINAPI RtlCaptureContext(PCONTEXT ContextRecord);
-#endif
-
static void LocalPrintStackTrace(raw_ostream &OS, PCONTEXT C) {
STACKFRAME64 StackFrame{};
CONTEXT Context{};
|
|
@llvm/pr-subscribers-llvm-support Author: Martin Storsjö (mstorsjo) ChangesAssume that mingw builds are made with mingw-w64 headers. The old mingw.org distribution isn't even accessible at the moment, and their project hosting site (osdn.net) seems to have been down for a couple of years, and their old project hosting (at sourceforge.net) hasn't been updated since 2018. Full diff: https://github.com/llvm/llvm-project/pull/145683.diff 1 Files Affected:
diff --git a/llvm/lib/Support/Windows/Signals.inc b/llvm/lib/Support/Windows/Signals.inc
index f11ad09f37139..959caa22f83ad 100644
--- a/llvm/lib/Support/Windows/Signals.inc
+++ b/llvm/lib/Support/Windows/Signals.inc
@@ -47,64 +47,6 @@
// back on at the end of the file.
#pragma GCC diagnostic ignored "-Wformat"
#pragma GCC diagnostic ignored "-Wformat-extra-args"
-
-#if !defined(__MINGW64_VERSION_MAJOR)
-// MinGW.org does not have updated support for the 64-bit versions of the
-// DebugHlp APIs. So we will have to load them manually. The structures and
-// method signatures were pulled from DbgHelp.h in the Windows Platform SDK,
-// and adjusted for brevity.
-typedef struct _IMAGEHLP_LINE64 {
- DWORD SizeOfStruct;
- PVOID Key;
- DWORD LineNumber;
- PCHAR FileName;
- DWORD64 Address;
-} IMAGEHLP_LINE64, *PIMAGEHLP_LINE64;
-
-typedef struct _IMAGEHLP_SYMBOL64 {
- DWORD SizeOfStruct;
- DWORD64 Address;
- DWORD Size;
- DWORD Flags;
- DWORD MaxNameLength;
- CHAR Name[1];
-} IMAGEHLP_SYMBOL64, *PIMAGEHLP_SYMBOL64;
-
-typedef struct _tagADDRESS64 {
- DWORD64 Offset;
- WORD Segment;
- ADDRESS_MODE Mode;
-} ADDRESS64, *LPADDRESS64;
-
-typedef struct _KDHELP64 {
- DWORD64 Thread;
- DWORD ThCallbackStack;
- DWORD ThCallbackBStore;
- DWORD NextCallback;
- DWORD FramePointer;
- DWORD64 KiCallUserMode;
- DWORD64 KeUserCallbackDispatcher;
- DWORD64 SystemRangeStart;
- DWORD64 KiUserExceptionDispatcher;
- DWORD64 StackBase;
- DWORD64 StackLimit;
- DWORD64 Reserved[5];
-} KDHELP64, *PKDHELP64;
-
-typedef struct _tagSTACKFRAME64 {
- ADDRESS64 AddrPC;
- ADDRESS64 AddrReturn;
- ADDRESS64 AddrFrame;
- ADDRESS64 AddrStack;
- ADDRESS64 AddrBStore;
- PVOID FuncTableEntry;
- DWORD64 Params[4];
- BOOL Far;
- BOOL Virtual;
- DWORD64 Reserved[3];
- KDHELP64 KdHelp;
-} STACKFRAME64, *LPSTACKFRAME64;
-#endif // !defined(__MINGW64_VERSION_MAJOR)
#endif // __MINGW32__
typedef BOOL(__stdcall *PREAD_PROCESS_MEMORY_ROUTINE64)(
@@ -536,12 +478,6 @@ void sys::PrintStackTraceOnErrorSignal(StringRef Argv0,
}
} // namespace llvm
-#if defined(__MINGW32__) && !defined(__MINGW64_VERSION_MAJOR)
-// Provide a prototype for RtlCaptureContext, mingw32 from mingw.org is
-// missing it but mingw-w64 has it.
-extern "C" VOID WINAPI RtlCaptureContext(PCONTEXT ContextRecord);
-#endif
-
static void LocalPrintStackTrace(raw_ostream &OS, PCONTEXT C) {
STACKFRAME64 StackFrame{};
CONTEXT Context{};
|
Is this documented in the requirements? It's fine in any case, but I feel like we should have it documented if people come searching for it. |
(That doesn't say exactly "mingw-w64" but, close enough to make it clear that it isn't mingw.org.) |
|
I guess that clear enough. There is no specific version requirement more than "recent"? Anyway don't let this side-track stop this PR :) |
Not sure, no. For the compiler, there's probably similar requirements on GCC/Clang as on other platforms (for modern enough C++17). For the mingw-w64 SDK I'm not aware of any specific requirement (we try to not require bleeding edge things, but specifically on architectures like aarch64 we may require a newer version than on x86/x86_64). In particular I'm not aware of anyone continuously testing with pinned old mingw-w64 versions though, so I'm not really aware of how old things we do work with. It probably would be good to do that occasionally though. :-) And for requirement specifications, some projects often refer to it just based on e.g. the GCC version, when it mostly implicitly means the version of mingw-w64 that happened to be packaged with that version of GCC, for some unnamed toolchain distribution. TL;DR, currently unclear, I guess someone should try it out and document it. But having it documented also would imply that we should recheck that we do uphold that and work with such an old version continuously. :-) |
…lvm#145683) Assume that mingw builds are made with mingw-w64 headers. The old mingw.org distribution isn't even accessible at the moment, and their project hosting site (osdn.net) seems to have been down for a couple of years, and their old project hosting (at sourceforge.net) hasn't been updated since 2018.
|
It was about time! |
5 participants
Assume that mingw builds are made with mingw-w64 headers.
The old mingw.org distribution isn't even accessible at the moment, and their project hosting site (osdn.net) seems to have been down for a couple of years, and their old project hosting (at sourceforge.net) hasn't been updated since 2018.