<div dir="ltr">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.<div><br></div><div>That said I don't feel that strongly about it, so don't let me block you.</div><div><br><div><div>Peter</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 2, 2016 at 7:00 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 2, 2016 at 7:45 PM, Evgeniy Stepanov via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">eugenis added a comment.<br>
<span><br>
In <a href="https://reviews.llvm.org/D27375#612431" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2737<wbr>5#612431</a>, @pcc wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D27375#612426" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2737<wbr>5#612426</a>, @eugenis wrote:<br>
><br>
> > 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.<br>
><br>
><br>
> Maybe only do it if isatty(stdout)?<br>
<br>
<br>
</span>This could work.<br>
<span><br>
><br>
><br>
>> 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.<br>
><br>
> Regarding UBSAN_SYMBOLIZER_PATH why add something for consistency with a deprecated env var?<br>
<br>
</span>That's also true.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D27375" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2737<wbr>5</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div>