llvm dev - May 2018 - Can creating new forms of debug info metadata be simplified? [formatting fixed]

[Resending due to accidental markdown rendering - sorry]

Hi list,

Let's talk about adding a new type of debug info metadata. Here are the
steps (at minimum - probably incomplete) one needs to take:
1. Create a new class in the hierarchy
2. Implement two forms of `MD_NODE_GET`
3. Specialize `MDNodeKeyImpl`
4. Modify `LLParser.cpp` and add serialization code for your
   special type5. Modify `AsmWriter.cpp` and add serialization code for your
   special type
I believe we can accomplish everything needed for debug info with just
step 1 using a pattern found in Boost Serialization. Imagine a new API
based on this concept:
```
class DIMyFancyType : public MDNode {
  StringRef FileName;

  template<typename Visitor>
  void visit(Visitor & v) {   DINode::visit(s); // or not, if you stay
  true to boost.serialization     v.name("DIMyFancyType");
     v.property("FileName",FileName);
  }
};
```

With this, we could implement steps 2-5 using a little bit of template
meta-programming and we could also implement escape hatches where needed
to get more specific, allowing us to keep many things in one place.
I imagine since there is now a `.def` file for the metadata (very
useful!) that this is on somebody's mind and not just my own, so I'm
curious about what people think. I realize that "new forms of debug
metadata" is possibly not a very popular use case as there has been only
one new kind added in the last few years. However, in my humble opinion,
it would make it easier to add richer information allowing those of us
extending LLVM to create better debuggers/debugging experiences.
Thanks for your time!

--
Sohail Somani
Fizz Buzz Inc.
Booking schedule: https://sohailsomani.youcanbook.me

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/e37bc47c/attachment.html>

+some of the debug info cabal (& Duncan, as an emeritus member, and person
who plumbed a lot of the current debug info syntax support in)

Visitor seems plausible though I haven't looked at the code in detail to
see if it'd work perfectly.

On Tue, May 29, 2018 at 7:56 AM Sohail Somani (Fizz Buzz Inc.) via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> [Resending due to accidental markdown rendering - sorry]
>
> Hi list,
>
> Let's talk about adding a new type of debug info metadata. Here are the
> steps (at minimum - probably incomplete) one needs to take:
>
> 1. Create a new class in the hierarchy
> 2. Implement two forms of `MD_NODE_GET`
> 3. Specialize `MDNodeKeyImpl`
> 4. Modify `LLParser.cpp` and add serialization code for your special type
> 5. Modify `AsmWriter.cpp` and add serialization code for your special type
>
> I believe we can accomplish everything needed for debug info with just
> step 1 using a pattern found in Boost Serialization. Imagine a new API
> based on this concept:
>
> ```
> class DIMyFancyType : public MDNode {
>   StringRef FileName;
>
>   template<typename Visitor>
>   void visit(Visitor & v) {
>      DINode::visit(s); // or not, if you stay true to boost.serialization
>      v.name("DIMyFancyType");
>      v.property("FileName",FileName);
>   }
> };
> ```
>
> With this, we could implement steps 2-5 using a little bit of template
> meta-programming and we could also implement escape hatches where needed to
> get more specific, allowing us to keep many things in one place.
>
> I imagine since there is now a `.def` file for the metadata (very useful!)
> that this is on somebody's mind and not just my own, so I'm curious
about
> what people think. I realize that "new forms of debug metadata"
is possibly
> not a very popular use case as there has been only one new kind added in
> the last few years. However, in my humble opinion, it would make it easier
> to add richer information allowing those of us extending LLVM to create
> better debuggers/debugging experiences.
>
> Thanks for your time!
>
> --
> Sohail Somani
> Fizz Buzz Inc.
> Booking schedule: https://sohailsomani.youcanbook.me
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/8f7f99e7/attachment.html>

> On May 29, 2018, at 12:28 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> +some of the debug info cabal (& Duncan, as an emeritus member, and
person who plumbed a lot of the current debug info syntax support in)
> 
> Visitor seems plausible though I haven't looked at the code in detail
to see if it'd work perfectly.
> 
> On Tue, May 29, 2018 at 7:56 AM Sohail Somani (Fizz Buzz Inc.) via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
> [Resending due to accidental markdown rendering - sorry]
> 
> Hi list,
> 
> Let's talk about adding a new type of debug info metadata. Here are the
steps (at minimum - probably incomplete) one needs to take:
> 
> 1. Create a new class in the hierarchy
> 2. Implement two forms of `MD_NODE_GET`
> 3. Specialize `MDNodeKeyImpl`
> 4. Modify `LLParser.cpp` and add serialization code for your special type
> 5. Modify `AsmWriter.cpp` and add serialization code for your special type 
> 
> I believe we can accomplish everything needed for debug info with just step
1 using a pattern found in Boost Serialization. Imagine a new API based on this
concept:
> 
> ```
> class DIMyFancyType : public MDNode {
>   StringRef FileName;
> 
>   template<typename Visitor>
>   void visit(Visitor & v) {
>      DINode::visit(s); // or not, if you stay true to boost.serialization
>      v.name <http://v.name/>("DIMyFancyType");
>      v.property("FileName",FileName);
>   }
> };
> ```
> 
> With this, we could implement steps 2-5 using a little bit of template
meta-programming and we could also implement escape hatches where needed to get
more specific, allowing us to keep many things in one place.
> 
> I imagine since there is now a `.def` file for the metadata (very useful!)
that this is on somebody's mind and not just my own, so I'm curious
about what people think. I realize that "new forms of debug metadata"
is possibly not a very popular use case as there has been only one new kind
added in the last few years. However, in my humble opinion, it would make it
easier to add richer information allowing those of us extending LLVM to create
better debuggers/debugging experiences.
Something (anything) along these lines seems like a good idea to me. In addition
to the cost of adding new nodes, having less repetitive manually-written
existing code reduces the chances for bugs and increases readability. There are
some irregularities in the existing code that I'm aware of that would need
to be still handled separately:
- The MDNodeKeyImpl currently is manually tuned to only hash members that are
likely to differ.
- The deserialization code also supports various older serialization formats.

-- adrian
> 
> Thanks for your time!
> 
> --
> Sohail Somani
> Fizz Buzz Inc.
> Booking schedule: https://sohailsomani.youcanbook.me
<https://sohailsomani.youcanbook.me/>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/efb1e0ab/attachment.html>