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

Balázs Benics via cfe-dev cfe-dev at lists.llvm.org
Mon Aug 17 13:03:59 PDT 2020


I made further experiments, but I'm not really satisfied.

Implementing the wished pretty-printers for the Static Analyzer seems
tricky.
It depends on a bunch of llvm and clang classes to have pretty-printers as
well.
Such as:
 - QualType
 - VarDecl
 - FunctionDecl
 - BinaryOperator::Opcode
 - APInt
 - etc.
Without these, the string representation that I could create is really
limited, beyond usable.

Let's see an example:
  Expected, using the `dump()` method - which we want to mimic statically:
    `&Element{SymRegion{reg_$0<char * src>},(reg_$1<int idx>) + 2,char}`
  Actual, using my current implementation:
    `&Element{SymRegion{reg_$0},(reg_$1) clang::BO_Add
APINT_PLACEHOLDER,TYPE_PLACEHOLDER}`

As you can see, `reg_$0` and `reg_$1` does not say much about the name of
the variable to it refers to.
The same goes for APINT_PLACEHOLDER and to the TYPE_PLACEHOLDER.

---

So, implementing these pretty-printers in a fully static way probably not
worth it.
It would be too much code to maintain and too fragile to refactors.
I'm afraid I don't have enough juice to implement all the pretty-printers
for the mentioned llvm, clang classes.
Despite these difficulties should I follow this direction?

Balázs Benics <benicsbalazs at gmail.com> ezt írta (időpont: 2020. aug. 6.,
Cs, 22:42):

> Unfortunately I have to chase some pointers, which are pointing to a class
> having virtual functions.
> I'm stuck for now, probably messed up some casts? Ah, writing pretty
> printers is dark magic.
>
> Yes, I planed to make use of the other printers as well as the default
> one.
> It's not working yet though.
>
>
> On Fri, Aug 7, 2020, 00:24 Sterling Augustine <saugustine at google.com>
> wrote:
>
>> On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <benicsbalazs at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>
>> 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.
>>
>> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200817/07d934a5/attachment.html>


More information about the cfe-dev mailing list