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

[David Blaikie via cfe-dev]

On Mon, Aug 17, 2020 at 1:04 PM Balázs Benics via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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?
>

Not sure which direction/what you're asking exactly. The question is
whether you should continue working on GDB pretty printers for clang types
using a fully static approach, when those printers won't be so fully
featured because to make them so would require implementing more pretty
printers for other lower level Clang and LLVM types?

I'd say the number of folks using gdb pretty printers is small enough that:
work on whatever helps you the most and if you're willing/able to make them
fully static & they're still useful to you with that limitation (if that
means without having added pretty printers for lower level types, because
you don't have time for it, etc) - then I think they'd be fine to go
upstream. People can always use "dump()" if the pretty printer isn't as
fully featured as dump is - it's not making anything worse.


>
> 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.
>>>
>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200831/501ef1b3/attachment.html>