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

[Nico Weber via cfe-commits]

I implemented Reid's suggestion in 258545. I tested that the test runs and
passes when the DIA SDK is around (this is usually the case), and doesn't
run when it isn't.

On Thu, Jan 21, 2016 at 2:09 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:

> 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/20160122/5fe5774c/attachment.html>