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

[Balázs Benics via cfe-dev]

What if I would generate the pretty printers at build time from the
SVals.def
<https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd7193eb3/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.def>,
Symbols.def
<https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd7193eb3/clang/include/clang/StaticAnalyzer/Core/PathSensitive/Symbols.def>
and Regions.def
<https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd7193eb3/clang/include/clang/StaticAnalyzer/Core/PathSensitive/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 <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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200805/4d94c3b8/attachment.html>