[PATCH] D96289: Add support for YAML output style to llvm-symbolizer

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D96289#2563945 <https://reviews.llvm.org/D96289#2563945>, @MaskRay wrote:

> In D96289#2562717 <https://reviews.llvm.org/D96289#2562717>, @aorlov wrote:
>
>> In D96289#2560919 <https://reviews.llvm.org/D96289#2560919>, @MaskRay wrote:
>>
>>> The line based output can be straightforwardly parsed
>
>
>
> - Most users parse the line based output, as they did with addr2line. There is a `--verbose` option which can make the output less ambiguous.  https://github.com/google/pprof/blob/master/internal/binutils/addr2liner_llvm.go#L113 is an example how easy/robust it is. (The Go tool is used by many groups in production.)

I don't really have any particular stake in this either way. I know our users in the past have wanted GNU addr2line-compatible output, which implies that they parse the output directly, and already have scripts to do so. Indeed the symbolizer is possibly the most commonly used tool from the smaller tools used by our end users. On the one hand, a JSON or YAML output would make new users' jobs simpler because it's easier to work with such output than having to manually write a parser. On the other hand, as you've pointed out, writing the parser for it isn't that complicated. Is it really worth us carrying the maintenance burden for this additional output style? I'm not opposed if there have been end user requests for it.

> - Users want a lot of flexibility - they should use the DebugInfo/Symbolize APIs.

This only works if a user is writing their parsing in C++, right? That being said, I don't know if there are any real users for this situation who wouldn't be building using the LLVM libraries.

> The two cover the spectrum I can think of. If really we need an interchange format (I have some doubts, after asking others, so it is not my own opinion), JSON seems a better choice.

Having given it more thought, +1 to using JSON over YAML. JSON has the advantage that it can be consumed directly by native python, without needing additional modules, and python is a regular choice for people writing scripts to parse output like this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96289/new/

https://reviews.llvm.org/D96289