<div dir="ltr"><div>I made further experiments, but I'm not really satisfied.<br><br>Implementing the wished pretty-printers for the Static Analyzer seems tricky.<br>It depends on a bunch of llvm and clang classes to have pretty-printers as well.<br>Such as:<br> - QualType<br> - VarDecl<br> - FunctionDecl<br> - BinaryOperator::Opcode<br> - APInt<br> - etc.<br>Without these, the string representation that I could create is really limited, beyond usable.<br><br>Let's see an example:<br>  Expected, using the `dump()` method - which we want to mimic statically:<br>    `&Element{SymRegion{reg_$0<char * src>},(reg_$1<int idx>) + 2,char}`<br>  Actual, using my current implementation:<br>    `&Element{SymRegion{reg_$0},(reg_$1) clang::BO_Add APINT_PLACEHOLDER,TYPE_PLACEHOLDER}`<br><br>As you can see, `reg_$0` and `reg_$1` does not say much about the name of the variable to it refers to.<br>The same goes for APINT_PLACEHOLDER and to the TYPE_PLACEHOLDER.<br><br>---<br><br>So, implementing these pretty-printers in a fully static way probably not worth it.<br>It would be too much code to maintain and too fragile to refactors.<br></div>I'm afraid I don't have enough juice to implement all the pretty-printers for the mentioned llvm, clang classes.<br><div>Despite these difficulties should I follow this direction?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Balázs Benics <<a href="mailto:benicsbalazs@gmail.com">benicsbalazs@gmail.com</a>> ezt írta (időpont: 2020. aug. 6., Cs, 22:42):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Unfortunately I have to chase some pointers, which are pointing to a class having virtual functions.<div dir="auto">I'm stuck for now, probably messed up some casts? Ah, writing pretty printers is dark magic. </div><div dir="auto"><br></div><div dir="auto">Yes, I planed to make use of the other printers as well as the default one. </div><div dir="auto">It's not working yet though. </div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, Aug 7, 2020, 00:24 Sterling Augustine <<a href="mailto:saugustine@google.com" target="_blank">saugustine@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <<a href="mailto:benicsbalazs@gmail.com" rel="noreferrer" target="_blank">benicsbalazs@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Just how much of a sub-object to dump is always a tricky call. Often the right call is at a pointer or reference boundary.</div><div><br></div><div>Note also that if you implement the children function of the gdb api for the top-level type, you will get any sub-pretty printers that exist for free. And if they don't exist, gdb will use its default printing mechanism, which is often good enough.</div></div></div>
</blockquote></div></div>
</blockquote></div>