[compiler-rt] r212815 - [ASan/Win] Don't apply dllexport to __asan_init in the DLL thunk

[Timur Iskhodzhanov]

On Windows, we currently have two RTLs -- the "full" one, linked to the
app; and a mini dll_thunk one, delegating ASan interface calls to the main
one.
The dllexport attribute should only be applied to interface functions
exported by the full/main one.
11 июля 2014 г. 22:28 пользователь "Alexey Samsonov" <vonosmas at gmail.com>
написал:

>
> On Fri, Jul 11, 2014 at 6:46 AM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>
>> Author: timurrrr
>> Date: Fri Jul 11 08:46:05 2014
>> New Revision: 212815
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=212815&view=rev
>> Log:
>> [ASan/Win] Don't apply dllexport to __asan_init in the DLL thunk
>>
>> This fixes '___asan_init_v4 already defined' errors when linking some of
>> Chromium DLLs.
>> Looks like one of the DLL is using a .lib produced while linking another
>> DLL and it exploded after r212699.
>> I'm trying to come up with a small testcase...
>>
>> Modified:
>>     compiler-rt/trunk/lib/asan/CMakeLists.txt
>>     compiler-rt/trunk/lib/sanitizer_common/sanitizer_internal_defs.h
>>
>> Modified: compiler-rt/trunk/lib/asan/CMakeLists.txt
>> URL:
>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/CMakeLists.txt?rev=212815&r1=212814&r2=212815&view=diff
>>
>> ==============================================================================
>> --- compiler-rt/trunk/lib/asan/CMakeLists.txt (original)
>> +++ compiler-rt/trunk/lib/asan/CMakeLists.txt Fri Jul 11 08:46:05 2014
>> @@ -179,7 +179,7 @@ else()
>>        add_compiler_rt_runtime(clang_rt.asan_dll_thunk-${arch} ${arch}
>> STATIC
>>          SOURCES asan_dll_thunk.cc
>>                  $<TARGET_OBJECTS:RTInterception.${arch}>
>> -        CFLAGS ${ASAN_CFLAGS} -DASAN_DLL_THUNK
>> +        CFLAGS ${ASAN_CFLAGS} -DASAN_DLL_THUNK -DSANITIZER_DLL_THUNK
>>          DEFS ${ASAN_COMMON_DEFINITIONS})
>>        add_dependencies(asan clang_rt.asan_dll_thunk-${arch})
>>      endif()
>>
>> Modified: compiler-rt/trunk/lib/sanitizer_common/sanitizer_internal_defs.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_internal_defs.h?rev=212815&r1=212814&r2=212815&view=diff
>>
>> ==============================================================================
>> --- compiler-rt/trunk/lib/sanitizer_common/sanitizer_internal_defs.h
>> (original)
>> +++ compiler-rt/trunk/lib/sanitizer_common/sanitizer_internal_defs.h Fri
>> Jul 11 08:46:05 2014
>> @@ -17,7 +17,11 @@
>>
>>  // Only use SANITIZER_*ATTRIBUTE* before the function return type!
>>  #if SANITIZER_WINDOWS
>> -# define SANITIZER_INTERFACE_ATTRIBUTE __declspec(dllexport)
>> +# if defined(SANITIZER_DLL_THUNK)
>> +#  define SANITIZER_INTERFACE_ATTRIBUTE
>> +# else
>> +#  define SANITIZER_INTERFACE_ATTRIBUTE __declspec(dllexport)
>> +# endif
>>
>
> I find this very confusing. sanitizer_common is not a header-only library,
> it's compiled once, and then the same object
> files are put inside all sanitizer runtimes (ASan, TSan, MSan). But ASan
> runtime #includes headers from sanitizer_common.
> If you build some parts of ASan runtime with "-DSANITIZER_FOO=1" and build
> sanitizer_common itself with "-DSANITIZER_FOO=0"
> you may get all sorts of weird bugs. So I kind of advocate against
> "SANITIZER_FOO" macro which are exposed in sanitizer_common headers.
>
> Is it possible to find other solution? What SANITIZER_INTERFACE_ATTRIBUTE
> are you trying to get rid of?
>
>
>
>>  // FIXME find out what we need on Windows, if anything.
>>  # define SANITIZER_WEAK_ATTRIBUTE
>>  #elif defined(SANITIZER_GO)
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140711/c0a3b934/attachment.html>