[cfe-dev] [analyzer] gdb pretty printers for analyzer specific types

[Balázs Benics via cfe-dev]

Sterling
> Hardcoding types inside a python pretty printer is more or less the
standard way of doing it.
I'm going this way then. Thank you.

> libcxx has some nicely implemented pretty printers for various standard
types.
Thanks, it was awesome.

Artem
> Do i understand correctly that you're basically advocating for a QoL
change that'll make lldb commands `p V` and `p V.dump()` equivalent?
Yes, I want to make debugging easier. For now, I want gdb pretty printers.

David
> Annoyingly that'd mean adding another different directory to load
> pretty printers from (in addition to the one already in the source
> tree)
Yea, but for now, I will be happy if I can get it working xD

=== Current state ===
I managed to create a custom cmake command to generate a python file, using
the def files and the C preprocessor to create the required enumeration
types.
It looks something like this:
```
from enum import Enum

#define Q(x) #x
#define QUOTE(x) Q(x)

#define BASIC_SVAL(Id, Parent) QUOTE(Id),
#define ABSTRACT_SVAL_WITH_KIND(Id, Parent) QUOTE(Id),
BaseKind = Enum('BaseKind', [
  #include "SVals.def"
], start=0)
#undef BASIC_SVAL
#undef ABSTRACT_SVAL_WITH_KIND

#define NONLOC_SVAL(Id, Parent) QUOTE(Id),
NonLocKind = Enum('NonLocKind', [
  #include "SVals.def"
], start=0)
#undef NONLOC_SVAL
```
... and so forth with the other enumerations.

So I can import the necessary enum type in the pretty printer
implementation.
Unfortunately, I have to reimplement the dump functions of the complete
SVal, MemRegion and SymExpr hierarchy.
Since those refer to other objects, like a FunctionDecl.
IMO the cost creating the pretty printers for them outweighs the benefit.
So I would stick to a simple placeholder in such cases.

---

I already have something like this:
[image: proof-of-concept.png]
Thanks for the comments.

Artem Dergachev <noqnoqneo at gmail.com> ezt írta (időpont: 2020. aug. 5.,
Sze, 21:27):

> Whoops, yeah, i mean, anyway, the question stands for gdb as well :)
>
> On 05.08.2020 13:29, David Blaikie wrote:
> > On Wed, Aug 5, 2020 at 12:16 PM Artem Dergachev via cfe-dev
> > <cfe-dev at lists.llvm.org> wrote:
> >> Do i understand correctly that you're basically advocating for a QoL
> change that'll make lldb commands `p V` and `p V.dump()` equivalent?
> > This wouldn't apply to lldb, unfortunately - gdb and lldb have
> > different pretty printer interfaces.
> >
> >> On 05.08.2020 10:40, Balázs Benics via cfe-dev wrote:
> >>
> >> I was thinking about some pretty printers.
> >> And I'm thinking about SVals and SymExprs specifically.
> >>
> >> Why do we have no pretty printers for such types?
> >>
> >> I guess we could reuse their dump() method to acquire string
> representation.
> >> The only problem is that that dumps the output to the standard error
> stream.
> >>
> >> What options do I have to get a python pretty-printer using this dump
> method?
> >>
> >> Another possible way to implement such a pretty printer is to hardcode
> the SVal
> >> kinds in python to do the right thing for each case.
> >> I'm not really a big fan of this way though.
> >>
> >> If you have experience with gdb pretty printers then your comments more
> then welcomed.
> >>
> >> Balazs.
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200806/937a11f3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proof-of-concept.png
Type: image/png
Size: 223477 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200806/937a11f3/attachment-0001.png>