[PATCH] D15363: [UBSan] Implement runtime suppressions (PR25066).

[Alexey Samsonov via cfe-commits]

On Thu, Jan 21, 2016 at 10:58 AM, Reid Kleckner <rnk at google.com> wrote:

> On Thu, Jan 21, 2016 at 10:47 AM, Nico Weber <thakis at chromium.org> wrote:
>
>> Oh, ok, let's not depend on lld then. So, we need to either determine if
>>> DIA SDK is available at compiler-rt configure time, or teach
>>> llvm-symbolizer.exe to tell us that (as we support standalone compiler-rt
>>> build)...
>>>
>>
>> Maybe the lit config file could compile a small program with clang-cl and
>> then run it through llvm-symbolizer and see if a symbol is returned?
>>
>
> I'd rather duplicate this check in compiler-rt than add auto-conf style
> tests to check-asan startup:
>   # See if the DIA SDK is available and usable.
>   set(MSVC_DIA_SDK_DIR "$ENV{VSINSTALLDIR}DIA SDK")
>   if (IS_DIRECTORY ${MSVC_DIA_SDK_DIR})
>     set(HAVE_DIA_SDK 1)
>   else()
>     set(HAVE_DIA_SDK 0)
>   endif()
>

Yes. It's not 100% correct, but probably fine to assume that if we failed
to find DIA SDK at configure time, so did llvm-symbolizer when it was built.


>
> It is also possible to change LLVMSymbolizer::SymbolizePC to return false
> when llvm-symbolizer returns no useful information.
>

Do we want LLVMSymbolizer::SymbolizePC to succeed if we fetched file/line
info, but not function name?
Also, there may well be another issue that will be hard to debug. It makes
sense to store information about what features of llvm-symbolizer we expect
to work explicitly.


> This will cause the sanitizers to try calling into dbghelp, which will
> probably work. It doesn't return PDB column info or work with dwarf, which
> is why we try llvm-symbolizer first. I think I made this change at one
> point, but I was asked to revert it or there were minor issues that didn't
> seem worth fixing.
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160121/3d73e682/attachment.html>