<div dir="ltr"><div>Sterling</div><div>> Hardcoding types inside a python pretty printer is more or less the standard way of doing it.</div><div>I'm going this way then. Thank you.<br></div><div><br></div><div>> libcxx has some nicely implemented pretty printers for various standard types.</div><div>Thanks, it was awesome.<br></div><div><br></div><div>Artem</div><div>> 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?</div><div>Yes, I want to make debugging easier. For now, I want gdb pretty printers.</div><div><br></div><div>David<br></div><div>> Annoyingly that'd mean adding another different directory to load<br>
> pretty printers from (in addition to the one already in the source<br>
> tree)</div><div>Yea, but for now, I will be happy if I can get it working xD</div><div><br></div><div>=== Current state ===<br></div><div>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.<br></div><div>It looks something like this:<br>```<br></div><div><span style="font-family:monospace">from enum import Enum<br><br>#define Q(x) #x<br>#define QUOTE(x) Q(x)<br><br>#define BASIC_SVAL(Id, Parent) QUOTE(Id),<br>#define ABSTRACT_SVAL_WITH_KIND(Id, Parent) QUOTE(Id),<br>BaseKind = Enum('BaseKind', [<br> #include "SVals.def"<br>], start=0)<br>#undef BASIC_SVAL<br>#undef ABSTRACT_SVAL_WITH_KIND<br><br>#define NONLOC_SVAL(Id, Parent) QUOTE(Id),<br>NonLocKind = Enum('NonLocKind', [<br> #include "SVals.def"<br>], start=0)<br>#undef NONLOC_SVAL</span><br>```<br></div><div>... and so forth with the other enumerations.</div><div><br></div><div>So I can import the necessary enum type in the pretty printer implementation.</div><div>Unfortunately, I have to reimplement the dump functions of the complete SVal, MemRegion and SymExpr hierarchy.<br></div><div>Since those refer to other objects, like a FunctionDecl.</div><div>IMO the cost creating the pretty printers for them outweighs the benefit.<br></div><div>So I would stick to a simple placeholder in such cases.<br></div><div><br>---<br><br></div><div>I already have something like this:<br><div><img src="cid:ii_kdjaqo9o0" alt="proof-of-concept.png" width="566" height="255"></div><div>Thanks for the comments.<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> ezt írta (időpont: 2020. aug. 5., Sze, 21:27):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Whoops, yeah, i mean, anyway, the question stands for gdb as well :)<br>
<br>
On 05.08.2020 13:29, David Blaikie wrote:<br>
> On Wed, Aug 5, 2020 at 12:16 PM Artem Dergachev via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> 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?<br>
> This wouldn't apply to lldb, unfortunately - gdb and lldb have<br>
> different pretty printer interfaces.<br>
><br>
>> On 05.08.2020 10:40, Balázs Benics via cfe-dev wrote:<br>
>><br>
>> I was thinking about some pretty printers.<br>
>> And I'm thinking about SVals and SymExprs specifically.<br>
>><br>
>> Why do we have no pretty printers for such types?<br>
>><br>
>> I guess we could reuse their dump() method to acquire string representation.<br>
>> The only problem is that that dumps the output to the standard error stream.<br>
>><br>
>> What options do I have to get a python pretty-printer using this dump method?<br>
>><br>
>> Another possible way to implement such a pretty printer is to hardcode the SVal<br>
>> kinds in python to do the right thing for each case.<br>
>> I'm not really a big fan of this way though.<br>
>><br>
>> If you have experience with gdb pretty printers then your comments more then welcomed.<br>
>><br>
>> Balazs.<br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote></div>