On Thu, Jan 21, 2016 at 10:58 AM, Reid Kleckner <r...@google.com> wrote:
> On Thu, Jan 21, 2016 at 10:47 AM, Nico Weber <tha...@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
vonos...@gmail.com
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
