[analyzer] gdb pretty printers for analyzer specific types

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
I was thinking about some pretty printers.
And I'm thinking about SVals and SymExprs specifically.

Why do we have no pretty printers for such types?

I guess we could reuse their dump() method to acquire string representation.
The only problem is that that dumps the output to the standard error stream.

What options do I have to get a python pretty-printer using this dump method?

Another possible way to implement such a pretty printer is to hardcode the SVal
kinds in python to do the right thing for each case.
I'm not really a big fan of this way though.

If you have experience with gdb pretty printers then your comments more then welcomed.

Balazs.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
We don't have many pretty printers because people haven't
implemented/desired them, I guess. I implemented a handful to start &
some folks added/improved on them a bit.

In general you don't want to call into the process's code in a pretty
printer if you can help it - because that risks heisenbugs (risks that
pretty printing a value could change the state of the process being
debugged) and doesn't work on core files (which have no running
process to interact with).

But sometimes it's hard to avoid & I think I've done it in one or two
places in the existing LLVM Pretty printers - so it's by no means an
impossibility.

On Wed, Aug 5, 2020 at 10:41 AM Balázs Benics via cfe-dev
<[hidden email]> wrote:

>
> I was thinking about some pretty printers.
> And I'm thinking about SVals and SymExprs specifically.
>
> Why do we have no pretty printers for such types?
>
> I guess we could reuse their dump() method to acquire string representation.
> The only problem is that that dumps the output to the standard error stream.
>
> What options do I have to get a python pretty-printer using this dump method?
>
> Another possible way to implement such a pretty printer is to hardcode the SVal
> kinds in python to do the right thing for each case.
> I'm not really a big fan of this way though.
>
> If you have experience with gdb pretty printers then your comments more then welcomed.
>
> Balazs.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
Hardcoding types inside a python pretty printer is more or less the standard way of doing it. A pretty printer has to be very closely tied to the type and structure of the type it is printing. The knowledge must be quite intimate, or it couldn't do a better job than your standard debug info printer.

libcxx has some nicely implemented pretty printers for various standard types (if I do say so myself). You could take those as examples.

I'll second the "avoid calling process code in a pretty printer". It might be better than nothing (particularly if there isn't a standard way to call the dump function), but it is invasive, and there is no reason to believe it wouldn't allocate memory (say, when concatenating a string), which can perturb the state of the program you are debugging.
 
On Wed, Aug 5, 2020 at 10:53 AM David Blaikie via cfe-dev <[hidden email]> wrote:
We don't have many pretty printers because people haven't
implemented/desired them, I guess. I implemented a handful to start &
some folks added/improved on them a bit.

In general you don't want to call into the process's code in a pretty
printer if you can help it - because that risks heisenbugs (risks that
pretty printing a value could change the state of the process being
debugged) and doesn't work on core files (which have no running
process to interact with).

But sometimes it's hard to avoid & I think I've done it in one or two
places in the existing LLVM Pretty printers - so it's by no means an
impossibility.

On Wed, Aug 5, 2020 at 10:41 AM Balázs Benics via cfe-dev
<[hidden email]> wrote:
>
> I was thinking about some pretty printers.
> And I'm thinking about SVals and SymExprs specifically.
>
> Why do we have no pretty printers for such types?
>
> I guess we could reuse their dump() method to acquire string representation.
> The only problem is that that dumps the output to the standard error stream.
>
> What options do I have to get a python pretty-printer using this dump method?
>
> Another possible way to implement such a pretty printer is to hardcode the SVal
> kinds in python to do the right thing for each case.
> I'm not really a big fan of this way though.
>
> If you have experience with gdb pretty printers then your comments more then welcomed.
>
> Balazs.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
What if I would generate the pretty printers at build time from the SVals.def, Symbols.def and Regions.def.
Just like we generate c++ code using X macros for these classes.

It would be aware of changing those definition files and the build system would regenerate the pretty printers.

Should I code this pretty printer generation in python as well?
And hook it into the build system via the add_custom_target?

Sterling Augustine <[hidden email]> ezt írta (időpont: 2020. aug. 5., Sze, 18:00):
Hardcoding types inside a python pretty printer is more or less the standard way of doing it. A pretty printer has to be very closely tied to the type and structure of the type it is printing. The knowledge must be quite intimate, or it couldn't do a better job than your standard debug info printer.

libcxx has some nicely implemented pretty printers for various standard types (if I do say so myself). You could take those as examples.

I'll second the "avoid calling process code in a pretty printer". It might be better than nothing (particularly if there isn't a standard way to call the dump function), but it is invasive, and there is no reason to believe it wouldn't allocate memory (say, when concatenating a string), which can perturb the state of the program you are debugging.
 
On Wed, Aug 5, 2020 at 10:53 AM David Blaikie via cfe-dev <[hidden email]> wrote:
We don't have many pretty printers because people haven't
implemented/desired them, I guess. I implemented a handful to start &
some folks added/improved on them a bit.

In general you don't want to call into the process's code in a pretty
printer if you can help it - because that risks heisenbugs (risks that
pretty printing a value could change the state of the process being
debugged) and doesn't work on core files (which have no running
process to interact with).

But sometimes it's hard to avoid & I think I've done it in one or two
places in the existing LLVM Pretty printers - so it's by no means an
impossibility.

On Wed, Aug 5, 2020 at 10:41 AM Balázs Benics via cfe-dev
<[hidden email]> wrote:
>
> I was thinking about some pretty printers.
> And I'm thinking about SVals and SymExprs specifically.
>
> Why do we have no pretty printers for such types?
>
> I guess we could reuse their dump() method to acquire string representation.
> The only problem is that that dumps the output to the standard error stream.
>
> What options do I have to get a python pretty-printer using this dump method?
>
> Another possible way to implement such a pretty printer is to hardcode the SVal
> kinds in python to do the right thing for each case.
> I'm not really a big fan of this way though.
>
> If you have experience with gdb pretty printers then your comments more then welcomed.
>
> Balazs.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
Do i understand correctly that you're basically advocating for a QoL change that'll make lldb commands `p V` and `p V.dump()` equivalent?

On 05.08.2020 10:40, Balázs Benics via cfe-dev wrote:
I was thinking about some pretty printers.
And I'm thinking about SVals and SymExprs specifically.

Why do we have no pretty printers for such types?

I guess we could reuse their dump() method to acquire string representation.
The only problem is that that dumps the output to the standard error stream.

What options do I have to get a python pretty-printer using this dump method?

Another possible way to implement such a pretty printer is to hardcode the SVal
kinds in python to do the right thing for each case.
I'm not really a big fan of this way though.

If you have experience with gdb pretty printers then your comments more then welcomed.

Balazs.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
On Wed, Aug 5, 2020 at 11:40 AM Balázs Benics <[hidden email]> wrote:
>
> What if I would generate the pretty printers at build time from the SVals.def, Symbols.def and Regions.def.
> Just like we generate c++ code using X macros for these classes.
>
> It would be aware of changing those definition files and the build system would regenerate the pretty printers.
>
> Should I code this pretty printer generation in python as well?

Annoyingly that'd mean adding another different directory to load
pretty printers from (in addition to the one already in the source
tree)

When I first added pretty printers (
https://lists.llvm.org/pipermail/llvm-dev/2016-May/100365.html ) I
discussed the possibility of using inline scripts (see option "(2)
annoying inline scripts version") which would avoid the need to add
new load paths (though you'd still have to tweak your gdbinit to allow
autoloading of scripts from your build tree in general I think) - now
that I think about it more, maybe it can be made less annoying than I
think it is. Maybe C++ raw string literals would make it fairly
maintainable to have python in the inline asm? Then the pretty printer
could be generated from .def files straight into the header or its
library implementation (preferably the library implementation - if you
can be sure the object will be pulled in by the linker for any users
who would want access to the pretty printer)?

Maybe worth giving that a shot?

> And hook it into the build system via the add_custom_target?
>
> Sterling Augustine <[hidden email]> ezt írta (időpont: 2020. aug. 5., Sze, 18:00):
>>
>> Hardcoding types inside a python pretty printer is more or less the standard way of doing it. A pretty printer has to be very closely tied to the type and structure of the type it is printing. The knowledge must be quite intimate, or it couldn't do a better job than your standard debug info printer.
>>
>> libcxx has some nicely implemented pretty printers for various standard types (if I do say so myself). You could take those as examples.
>>
>> I'll second the "avoid calling process code in a pretty printer". It might be better than nothing (particularly if there isn't a standard way to call the dump function), but it is invasive, and there is no reason to believe it wouldn't allocate memory (say, when concatenating a string), which can perturb the state of the program you are debugging.
>>
>> On Wed, Aug 5, 2020 at 10:53 AM David Blaikie via cfe-dev <[hidden email]> wrote:
>>>
>>> We don't have many pretty printers because people haven't
>>> implemented/desired them, I guess. I implemented a handful to start &
>>> some folks added/improved on them a bit.
>>>
>>> In general you don't want to call into the process's code in a pretty
>>> printer if you can help it - because that risks heisenbugs (risks that
>>> pretty printing a value could change the state of the process being
>>> debugged) and doesn't work on core files (which have no running
>>> process to interact with).
>>>
>>> But sometimes it's hard to avoid & I think I've done it in one or two
>>> places in the existing LLVM Pretty printers - so it's by no means an
>>> impossibility.
>>>
>>> On Wed, Aug 5, 2020 at 10:41 AM Balázs Benics via cfe-dev
>>> <[hidden email]> wrote:
>>> >
>>> > I was thinking about some pretty printers.
>>> > And I'm thinking about SVals and SymExprs specifically.
>>> >
>>> > Why do we have no pretty printers for such types?
>>> >
>>> > I guess we could reuse their dump() method to acquire string representation.
>>> > The only problem is that that dumps the output to the standard error stream.
>>> >
>>> > What options do I have to get a python pretty-printer using this dump method?
>>> >
>>> > Another possible way to implement such a pretty printer is to hardcode the SVal
>>> > kinds in python to do the right thing for each case.
>>> > I'm not really a big fan of this way though.
>>> >
>>> > If you have experience with gdb pretty printers then your comments more then welcomed.
>>> >
>>> > Balazs.
>>> > _______________________________________________
>>> > cfe-dev mailing list
>>> > [hidden email]
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
On Wed, Aug 5, 2020 at 12:16 PM Artem Dergachev via cfe-dev
<[hidden email]> wrote:
>
> Do i understand correctly that you're basically advocating for a QoL change that'll make lldb commands `p V` and `p V.dump()` equivalent?

This wouldn't apply to lldb, unfortunately - gdb and lldb have
different pretty printer interfaces.

>
> On 05.08.2020 10:40, Balázs Benics via cfe-dev wrote:
>
> I was thinking about some pretty printers.
> And I'm thinking about SVals and SymExprs specifically.
>
> Why do we have no pretty printers for such types?
>
> I guess we could reuse their dump() method to acquire string representation.
> The only problem is that that dumps the output to the standard error stream.
>
> What options do I have to get a python pretty-printer using this dump method?
>
> Another possible way to implement such a pretty printer is to hardcode the SVal
> kinds in python to do the right thing for each case.
> I'm not really a big fan of this way though.
>
> If you have experience with gdb pretty printers then your comments more then welcomed.
>
> Balazs.
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
Whoops, yeah, i mean, anyway, the question stands for gdb as well :)

On 05.08.2020 13:29, David Blaikie wrote:

> On Wed, Aug 5, 2020 at 12:16 PM Artem Dergachev via cfe-dev
> <[hidden email]> wrote:
>> Do i understand correctly that you're basically advocating for a QoL change that'll make lldb commands `p V` and `p V.dump()` equivalent?
> This wouldn't apply to lldb, unfortunately - gdb and lldb have
> different pretty printer interfaces.
>
>> On 05.08.2020 10:40, Balázs Benics via cfe-dev wrote:
>>
>> I was thinking about some pretty printers.
>> And I'm thinking about SVals and SymExprs specifically.
>>
>> Why do we have no pretty printers for such types?
>>
>> I guess we could reuse their dump() method to acquire string representation.
>> The only problem is that that dumps the output to the standard error stream.
>>
>> What options do I have to get a python pretty-printer using this dump method?
>>
>> Another possible way to implement such a pretty printer is to hardcode the SVal
>> kinds in python to do the right thing for each case.
>> I'm not really a big fan of this way though.
>>
>> If you have experience with gdb pretty printers then your comments more then welcomed.
>>
>> Balazs.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
Sterling
> Hardcoding types inside a python pretty printer is more or less the standard way of doing it.
I'm going this way then. Thank you.

> libcxx has some nicely implemented pretty printers for various standard types.
Thanks, it was awesome.

Artem
> Do i understand correctly that you're basically advocating for a QoL change that'll make lldb commands `p V` and `p V.dump()` equivalent?
Yes, I want to make debugging easier. For now, I want gdb pretty printers.

David
> Annoyingly that'd mean adding another different directory to load
> pretty printers from (in addition to the one already in the source
> tree)
Yea, but for now, I will be happy if I can get it working xD

=== Current state ===
I managed to create a custom cmake command to generate a python file, using the def files and the C preprocessor to create the required enumeration types.
It looks something like this:
```
from enum import Enum

#define Q(x) #x
#define QUOTE(x) Q(x)

#define BASIC_SVAL(Id, Parent) QUOTE(Id),
#define ABSTRACT_SVAL_WITH_KIND(Id, Parent) QUOTE(Id),
BaseKind = Enum('BaseKind', [
  #include "SVals.def"
], start=0)
#undef BASIC_SVAL
#undef ABSTRACT_SVAL_WITH_KIND

#define NONLOC_SVAL(Id, Parent) QUOTE(Id),
NonLocKind = Enum('NonLocKind', [
  #include "SVals.def"
], start=0)
#undef NONLOC_SVAL

```
... and so forth with the other enumerations.

So I can import the necessary enum type in the pretty printer implementation.
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.
IMO the cost creating the pretty printers for them outweighs the benefit.
So I would stick to a simple placeholder in such cases.

---

I already have something like this:
proof-of-concept.png
Thanks for the comments.

Artem Dergachev <[hidden email]> ezt írta (időpont: 2020. aug. 5., Sze, 21:27):
Whoops, yeah, i mean, anyway, the question stands for gdb as well :)

On 05.08.2020 13:29, David Blaikie wrote:
> On Wed, Aug 5, 2020 at 12:16 PM Artem Dergachev via cfe-dev
> <[hidden email]> wrote:
>> Do i understand correctly that you're basically advocating for a QoL change that'll make lldb commands `p V` and `p V.dump()` equivalent?
> This wouldn't apply to lldb, unfortunately - gdb and lldb have
> different pretty printer interfaces.
>
>> On 05.08.2020 10:40, Balázs Benics via cfe-dev wrote:
>>
>> I was thinking about some pretty printers.
>> And I'm thinking about SVals and SymExprs specifically.
>>
>> Why do we have no pretty printers for such types?
>>
>> I guess we could reuse their dump() method to acquire string representation.
>> The only problem is that that dumps the output to the standard error stream.
>>
>> What options do I have to get a python pretty-printer using this dump method?
>>
>> Another possible way to implement such a pretty printer is to hardcode the SVal
>> kinds in python to do the right thing for each case.
>> I'm not really a big fan of this way though.
>>
>> If you have experience with gdb pretty printers then your comments more then welcomed.
>>
>> Balazs.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
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 <[hidden email]> wrote:
On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev
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 <[hidden email]> 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 <[hidden email]> wrote:
On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia via cfe-dev


On Mon, Aug 17, 2020 at 1:04 PM Balázs Benics via cfe-dev <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [analyzer] gdb pretty printers for analyzer specific types

Hollman, Daisy Sophia 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
On Thu, Aug 6, 2020 at 2:16 PM Balázs Benics <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev