[LLVMdev] compiler-rt with MSVC 2013 (original) (raw)

Aaron Ballman aaron at aaronballman.com
Thu Oct 23 12:42:54 PDT 2014

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote:

On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote:

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote:

2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>:

On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote:

I don't think this is the right approach.

Currently we intentionally define malloc etc without changing the names and (when stuff works ok) the linker just links all the mem allocator calls with calls to our RTL. This is kind of a link-time interception. How could that work in the presence of also having the MSVC CRT libraries linked in? When the linker finds the duplicate definition of any of those functions, it will produce that link error. You can use /FORCE:multiple to work around that, but then any usage of free() within compiler-rt is liable to find the asan definition. I don't know, it just worked :) LoL, not a vote of confidence. ;-) _I'm not 100% sure off the top of my head but I think asaninit is explicitly called from the CRT init code later than calloc gets called() from CRT. To handle everything correctly, calloc() must be _"statically" intercepted before asaninit is called from the CRT (hence before "dynamic" interceptors are set up). Can you please compare what happens in your build configuration compared to: $ cmake -GNinja -DLLVMENABLEASSERTIONS=ON -DCMAKEBUILDTYPE=Release -DLLVMTARGETSTOBUILD=X86 .. && ninja instead? Do I need something special to support ninja? Put it onto your PATH? e.g. you can $ svn export http://src.chromium.org/svn/trunk/tools/depottools/ninja.exe and put it into your cmake/bin That worked, and it does compile. I know basically nothing about ninja... is there a way to see what flags it passes to link.exe? I've found a way to check the linker output from the two builds, and they are different. From the ninja build, with /VERBOSE passed to the linker: Searching D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\LIB\LIBCMT.lib: ... At the same stage of linking, from the MSVC build, with /VERBOSE passed to the linker: 2> Searching D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\MSVCRT.lib: ... _2> Found imp_free 2> Referenced in MSVCRT.lib(crtdll.obj) 2> Loaded MSVCRT.lib(MSVCR120.dll) 2>MSVCRT.lib(MSVCR120.dll) : error LNK2005: free already defined in asanmallocwin.obj ... The ninja build has: Processed /DISALLOWLIB:libcmtd.lib Processed /DISALLOWLIB:msvcrt.lib Processed /DISALLOWLIB:msvcrtd.lib The MSVC build has: 2> Processed /DEFAULTLIB:kernel32.lib 2> Processed /DISALLOWLIB:libcmt.lib 2> Processed /DISALLOWLIB:libcmtd.lib 2> Processed /DISALLOWLIB:msvcrtd.lib So the two builds are not equivalent; the ninja build is somehow disallowing msvcrt.lib while the MSVC build is not.

I should note that libcmt.lib is what you get with /MT, and msvcrt.lib is what you get with /MD. I do not understand why Ninja seems to have the libraries associated with /MT when linking the DLL ([100/100] Linking CXX shared library lib\asan\clang_rt.asan_dynamic-i386.dll is where I pulled those lines from).

~Aaron

More information about the llvm-dev mailing list