This patch changes linkage with dbghlp.dll for clang from static (at load time) to on demand (at the first use of required functions). Clang uses dbghlp.dll only in minor use-cases. First of all in case of crash and in case of plugin load. The dbghlp.dll library can be absent on system. In this case clang will fail to load. With lazy load of dbghlp.dll clang can work even if dbghlp.dll is not available.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This was done for supporting mingw distributions without 64-bit versions of the DebugHlp APIs (please, see lib/Support/Windows/Signals.inc line 49 and below). Existing code base has already implemented dll loading part for some cases so I have prepared the patch as close to current implementation as possible.
I don't really know much about MinGW, and i also am not in a position to be
able to look at any code right now as I'm technically OOO for another 3
weeks. That said, if it is possible to make this work as a delayload dll,
it would be much preferred, even if it strays from some existing
implementation that does something different. With MSVC, this is as simple
as adding a linker flag, and you don't have to change even 1 line of code.
I'm not sure if MinGW toolchain supports this, but please check first. I'll
leave the final lgtm to someone else on this review.
Can you remove the configure and cmake test for libimagehlp along with this? Don't worry about regenerating autoconf, I can get Eric to do that.
I have checked MinGW possibilities and have not found easy way for delay loading. So at this moment I see following aproaches for this issue:
- Leave manual loading for MinGW in the code but use MSVC -delayload linker flag. The main drawback of this approach is two different ways for implementing lazy loading of imghelp.dll.
- Use dlltool (https://sourceware.org/binutils/docs/binutils/dlltool.html) for MinGW to generate imghelp.a file with lazy loading and simple -delayload linker flag for MSVC. This approach removes manual loading code from the patch, but adds configuration code for launching dlltool and most probably def file. Moreover, some of MinGW implementations don't provide --output-delaylib parameter (for example, 4.3 and lower). So building of LLVM may be impossible for this versions.
- Use manual loading for both compilers. This approach has evident benefit with same implementation for both compilers (msvc, mingw) and without using of extra tools.
The additional issue with automatic DLL delay loading is error handling. By default, application will fail in case of DLL absense, if there are no hooks or SEH handlers (https://msdn.microsoft.com/en-us/library/3aeywt27.aspx). So for automatic delay-loaded DLLs we have to write such hooks/handlers. Manual loading aproach doesn't have such drawback.
I'm fine with the dynamic approach over the delayload approach. We use this DLL so infrequently that it's fine.
configure | ||
---|---|---|
8661 | configure is a generated file. You want to change llvm/autoconf/configure.ac, and let Eric run autoconf to update this file. |
- configure changes were removed;
- autoconf/configure.ac tesing of imghelp was removed.
configure is a generated file. You want to change llvm/autoconf/configure.ac, and let Eric run autoconf to update this file.