[PATCH] D27375: Let ubsan search UBSAN_SYMBOLIZER_PATH for llvm-symbolizer

[Nico Weber via llvm-commits]

I don't feel strongly either. I was surprised by the lack of this, so I
sent a patch, but I don't know if having this is a good idea. Your point is
a good point, maybe we should just put it in the docs. Then again, doesn't
this apply to ASAN_OPTIONS and UBSAN_OPTIONS too? Or is there a reason why
those both exist?

On Dec 2, 2016 10:33 PM, "Peter Collingbourne" <peter at pcc.me.uk> wrote:

> I think the difference here is that unlike the other sanitizers that
> support *_SYMBOLIZER_PATH UBSan can be used with other sanitizers. If we
> have UBSAN_SYMBOLIZER_PATH we'll basically be in a confusing situation
> where UBSan does different things depending on whether it is used
> standalone or with another sanitizer.
>
> That said I don't feel that strongly about it, so don't let me block you.
>
> Peter
>
> On Fri, Dec 2, 2016 at 7:00 PM, Nico Weber <thakis at chromium.org> wrote:
>
>> On the other hand, options are set via ASAN_OPTIONS, UBSAN_OPTIONS, etc,
>> not via some SANITIZER_OPTIONS var that all the sanitizers understand.
>> Currently, things are fairly consistent (and after this change, even more
>> so). Declaring the existing ASAN_SYMBOLIZER_PATH etc as deprecated,
>> introducing a new LLVM_SANITIZER_PATH thing (does gcc's asan use the
>> runtime in compiler-rt, or do they have their own runtime?), and adding
>> deprecation output introduces quite a bit of turmoil that'll take a release
>> or two (6-12 months) to settle down, and the state we get to isn't that
>> much better than where we are right now.
>>
>> On Fri, Dec 2, 2016 at 7:45 PM, Evgeniy Stepanov via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> eugenis added a comment.
>>>
>>> In https://reviews.llvm.org/D27375#612431, @pcc wrote:
>>>
>>> > In https://reviews.llvm.org/D27375#612426, @eugenis wrote:
>>> >
>>> > > I can imagine a separate environment variable being more convenient
>>> in some cases. I don't think we should deprecate it. Also, printing stuff
>>> can break user programs, so it should not be done by default, and doing it
>>> only with verbosity=1 is almost useless, no one will see it.
>>> >
>>> >
>>> > Maybe only do it if isatty(stdout)?
>>>
>>>
>>> This could work.
>>>
>>> >
>>> >
>>> >> I'd add LLVM_SYMBOLIZER_PATH, maybe add UBSAN_SYMBOLIZER_PATH (just
>>> for consistency), and change the docs to point to LLVM_SYMBOLIZER_PATH and
>>> external_symbolizer_path.
>>> >
>>> > Regarding UBSAN_SYMBOLIZER_PATH why add something for consistency with
>>> a deprecated env var?
>>>
>>> That's also true.
>>>
>>>
>>> https://reviews.llvm.org/D27375
>>>
>>>
>>>
>>>
>>
>
>
> --
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161203/37584f4c/attachment.html>