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

[Balázs Benics via cfe-dev]

> [...] 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?
Exactly.

> I think they'd be fine to go upstream.
We will see, I will try to spare time to finish the current state before
upstreaming.
As you said, "it's not making anything worse" :)

Thanks.

David Blaikie <dblaikie at gmail.com> ezt írta (időpont: 2020. aug. 31., H,
16:49):

>
>
> 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/f249ad9d/attachment.html>