27 Aug
2012
27 Aug
'12
9:11 p.m.
Am 27.08.2012 15:45, schrieb Jérôme Gardou:
In fact, MS uses 2 versions of DllMain. One in the static crt and
one in
msvcrt.lib. And the latter does in fact call DisableThreadLibraryCalls.
So you are right.
The DllMainCRTStartup from mingw-w64 handles them, but the code is so
***** that I didn't see, that this runs into nowhere and it does not do
anything with them.
We just need to make sure this DllMain is not included in our static
CRT, even though that one is probably not usable for compiling a proper
dll anyway.
That is normal and expectable linker behaviour. LD works the same way
(unless it's totally fubar). The function from the lib does not get
included, if it's present in the main object files. (This only works on
a per file basis. So when the function was in the same compilation unit
as a second function that was linked into the dll, then the function
would also be forced in and it would result in an error about multiple
definitons.)
So under the circumstance that the programmer is sane and doesn't put
his DllMain into a static library, you can happily add a stubbed version.
Therefore I suggest:
- Add the DllMain for both GCC and MSVC
- Don't use a weak symbol and do not check "if (DllMain)" and instead
keep the original code unmodified
Please don't make unneccessary modifications to 3rd party code, based on
the fear, that LD *might* be broken.
Thanks,
Timo
Hi.
Please see the inlined answers.
Timo Kreuzer a écrit :
No, I was talking about DllMain. It is not in our codebase, but
in
mingw-w64. I even have the file in my working copy, probably from the
last sync, but I didn't commit it for whatever reason.
Hi,
I don't agree with these changes.
If we need a DllEntry in the lib, then we should use the one that is
provided by mingw-w64 (all this code is 100% mingw-w64). It simply
returns true (thats exactly what the one in MS CRT does) and works for
gcc and MSVC.
There is DllEntryPoint in the code base, but no DllMain. Is it what
you
are talking about? Also what's the point of
DisableThreadLibraryCalls() here? As you wrote
yourself, no DllMain only means "I have nothing more to initialize than
the CRT". But this disables the CRT thread initializion, too.
You have a
point. If nothing is given, then the programmer could
assume that nothing happens.
Regarding CRT thread initialization: DisableThreadLibraryCalls means
that the DLLs ahs nothing to initialize on thread creation, and that
the loader can gain some performance in skipping this DLL. We have
some Dlls that call it, and if this is a problem with our CRT, then
this is bad.
Quoting MSDN:
"Do not call this function from a DLL that is linked to the static C
run-time library (CRT). The static CRT requires DLL_THREAD_ATTACH and
DLL_THREAD_DETATCH notifications to function properly"
Reading between the lines, that means that every CRT thread
initialization is done in msvcrt.dll, and nowhere else. What we link
statically to our DLLs shouldn't have anything to do on thread
initializations. There is also no need for weak symbols, we can
simply call the stub
DllMain, since it doesn't (shouldn't) do anything.
As said in the comment,
link.exe choses symbols defined in the object
files it is given, and then in the libraries. So adding a stubbed
version of dllmain in our library is harmless (unless someone puts his
DllMain in a static library and links to that library.) I don't really
know about ld behaviour regarding this case, and the
"--allow-multiple-definition" option of ld (see
http://sourceware.org/binutils/docs-2.22/ld/Options.html#Options )
scares me.