[Lldb-commits] [PATCH] D85705: Add a "Trace" plug-in to LLDB to add process trace support in stages.

Wed Aug 26 12:51:02 PDT 2020

JDevlieghere added a comment.

In D85705#2237506 <https://reviews.llvm.org/D85705#2237506>, @clayborg wrote:

> In D85705#2237397 <https://reviews.llvm.org/D85705#2237397>, @JDevlieghere wrote:
>
>> A large part of this patch is concerned with parsing which worries me from a maintenance perspective. Did you consider using Yaml I/O <https://llvm.org/docs/YamlIO.html>? While I'm not a particularly big fan of the format, the benefits of being able to (de)serialize any class by implementing the appropriate traits are quite significant. We already have traits implemented for a bunch of utility classes, such as `ArchSpec` and `FileSpec` which we could reuse for this. I know changing the format would be invasive, but I think it might be worth it in the long term.
>
> So the nice thing about using StructuredData is it can be in any format: JSON, XML, Apple property list, YAML etc. It seems like the functions that were added to ArchSpec and FileSpec for the YAML I/O could be converted to use StructuredData and then any of the formats would work.

If we invest in creating a library like Yaml IO for StructuredData, which allows you to declaratively specify how a class gets (de)serialized, then I'm all for using it here and for the reproducers. I think that would be really, really valuable. Given the way that structured data works and how similar it is to how these formats look, I'm also fairly confident it can be done. Still it would be a significant amount of work. But barring that I don't see a benefit from switching from YAML I/O to StructuredData, at least not for the reproducers and not really for this either. Unless we need to be able to support all these formats? Like I said, I don't really care about YAML. What I do care about is that I don't want to be in the business of writing a parser for every data structure I need to serialize. That's really where Yaml I/O shines, even though it has other drawbacks, like the traits themselves being verbose and the parser being far from fast.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85705