[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