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

[David Blaikie via cfe-dev]

On Wed, Aug 5, 2020 at 11:40 AM Balázs Benics <benicsbalazs at gmail.com> 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 <saugustine at google.com> 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 <cfe-dev at lists.llvm.org> 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
>>> <cfe-dev at lists.llvm.org> 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
>>> > cfe-dev at lists.llvm.org
>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev