27197, "jabraham17", "[Design]: Adding debug pretty print functions to Chapel", "2025-04-30T22:58:51Z"
In a recent demo, I showed some preliminary work for adding debug pretty printers to Chapel. This builds on some work showcased by students at WWU at Chapelcon 2024. These pretty printers allow Chapel users to print out variables as writeln would while debugging programs, regardless of the effects of munging. This is especially impactful for variables like arrays, which are otherwise opaque to gdb/lldb.
The way that the above is achieved is by stamping out extra code for printing various types. The debugger can then look these functions up and call them. While this works great, it has two big downsides: increased compilation time and increased binary size. I think work can be done to improve this (like being more careful about what types actually need to be stamped out), but fundamentally this is unavoidable.
How should we handle this? I think its important that users have control over this, likely through a compiler flag like --debug-pretty-print (straw proposal name). What should the default for this flag be? Should it be tied to any other compiler flag by default (e.g. -g implies --debug-pretty-print unless --no-debug-pretty-print is specified).
It might also be useful to provide other knobs to users for this. For example, have a very small subset of types be included by default and let users add more with --debug-pretty-print-types=<regex>. I think this would pair well with an attribute like @generatePrettyPrinter to allow this to be written in code. We could also consider a tiering approach to avoid forcing users to list every single type they want to debug, something like --debug-pretty-print-types=[minimal|all|....].