[llvm-dev] [RFC] Tooling for parsing and symbolication of Sanitizer reports

[Dan Liew via llvm-dev]

>> I was operating under the assumption that the decision made in
>> https://github.com/google/sanitizers/issues/268 was still the status
>> quo. That was six years ago though so I'll let Kostya chime in here if
>> he now thinks differently about this.
>
>
> My opinion on the matter didn't change, nor did the motivation.
> I am opposed to making the sanitizer run-time any more complex,
> and I prefer the approach proposed here: separate, adjacently maintained parser.

Okay. If this is your position can we proceed to review
https://reviews.llvm.org/D88938 ?

> On top of the previous motivation, here is some more.
> We are going to have more sanitizer-like things in the near future (Arm MTE is one of them),
> that are not necessarily going to be in LLVM and that will not emit JSON.
> (and they shouldn't: we don't want any such thing in a production run-time).
> But we can support those things with a separate parser.

Just to push back on this a little. I don't think emitting JSON is any
worse than what we do today. It's still just printing strings to a
file/system log.
Out of curiosity, how would you propose a production run-time emit
"sanitizer" like reports? Maybe a special purpose syscall and then
trap?

> I have a mild preference to have the parser written as a C++ library, with C interface.
> Not in python, so that it can be used programmatically w/o launching a sub-process.
> But I don't insist (especially given the code is written already)

My reasons for writing this in Python are:

* Support for extending the tool with plug-ins is planned. Python
makes writing plug-ins easy. Writing plugins in a C++ world is fraught
with problems.
* A functioning tool can be built very quickly due to Python's large
ecosystem (stdlib and external packages).

We could certainly rewrite parts of the tool in C++ in should we
actually need it in the future. Right now though Python seems like the
better choice.

Thanks,
Dan.