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.
