[LLVMdev] Win32: Crash in DLL created by llvm that calls into the "putchar" function

Daniel Albuschat d.albuschat at gmail.com
Sun Dec 8 10:10:25 PST 2013


2013/12/8 Daniel Albuschat <d.albuschat at gmail.com>:
> Hey Jeremy,
>
> (putting the discussion back to the list.)
>
> 2013/12/8 Jeremy Lakeman <Jeremy.Lakeman at gmail.com>:
>> If I run your demo exe it crashes, if I re-link the dll with VS 2010 it
>> errors gracefully;
>>
>> runtime error R6030
>> - CRT not initialized
>>
>> putchar is a c runtime function.
>> I'm betting that your exe doesn't initialise the runtime library?
>
> You're right, this is surely the problem then. Thanks a buch for that pointer.
> However, after quite much googling, I can't find a way to correctly
> initialize the CRT in a DLL created from llvm.
> From what I've learned, the system works as follows:
>
> * The entry point for DLLs in __DllMainCRTStartup at 12.
> * The CRT libraries provide an implementation for this function in libcmt.lib.
> * That implementation initializes the CRT (afaik using CRT_INIT) and
> calls DllMain.
>
> The question that remains is how to dllexport a function that is
> defined in a separate library?

Actually, I answered that question just a few seconds later. ;-)
I just forgot to pass LIBCMT.LIB to link.exe in my previous tries.

Here's the working .ll file that can be used to create a .dll that
calls into the putchar function:

> cat callPutchar.ll
; ModuleID = 'test'

declare i32 @putchar(i32)
declare x86_stdcallcc i8 @DllMainCRTStartup(i32*, i32, i32*)

define dllexport i32 @main() {
__entry__:
  %0 = call i32 @putchar(i32 79)
  ret i32 %0
}

define dllexport x86_stdcallcc i8 @DllMain(i32*, i32, i32*) {
    ret i8 1
}


> llc -filetype obj callPutchar.ll

> link /DLL /SUBSYSTEM:CONSOLE callPutchar.obj LIBCMT.LIB
Microsoft (R) Incremental Linker Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

   Bibliothek "callPutchar.lib" und Objekt "callPutchar.exp" werden erstellt.

d:\callPutchar>demoDllCaller.exe
O

YAY!

Thanks again, Jeremy.

Daniel



More information about the llvm-dev mailing list