On 3/27/13, Richard Biener <richard.guent...@gmail.com> wrote: > On Mar 27, 2013, Lawrence Crowl <cr...@googlers.com> wrote: >> Patch with rename to debug attached. >> Tested on x86_64. >> >> >> Add uniform debug dump function names. >> >> >> Add some overloaded functions that provide uniform debug dump >> function names. These names are: >> >> debug: the general debug dumper >> debug_verbose: for more details >> debug_raw: for the gory details >> debug_head: for the heads of declarations, e.g. function heads >> debug_body: for the bodies of declarations, e.g. function bodies >> >> Not all types have the last four versions. >> >> The debug functions come in two flavors, those that take pointers >> to the type, and those that take references to the type. The first >> handles printing of '<nil>' for null pointers. The second assumes >> a valid reference, and prints the content. >> >> >> Example uses are as follows: >> >> cp_token t, *p; >> debug (t); >> debug (p); >> >> From the debugger, use >> >> call debug (t) >> >> >> The functions sets implemented are: >> >> debug (only) >> >> basic_block_def, const bitmap_head_def, cp_binding_level, >> cp_parser, cp_token, data_reference, die_struct, edge_def, >> gimple_statement_d, ira_allocno, ira_allocno_copy, live_range, >> lra_live_range, omega_pb_d, pt_solution, const rtx_def, sreal, >> tree_live_info_d, _var_map, >> >> vec<cp_token, va_gc>, vec<data_reference_p>, vec<ddr_p>, >> vec<rtx>, vec<tree, va_gc>, >> >> debug and debug_raw >> >> simple_bitmap_def >> >> debug and debug_verbose >> >> expr_def, struct loop, vinsn_def >> >> debug, debug_raw, debug_verbose, debug_head, debug_body >> >> const tree_node >> >> >> This patch is somewhat different from the original plan at >> gcc.gnu.org/wiki/cxx-conversion/debugging-dumps. The reason >> is that gdb has an incomplete implementation of C++ call syntax; >> requiring explicit specification of template arguments and explicit >> specification of function arguments even when they have default >> values. So, the original plan would have required typing >> >> call dump <cp_token> (t, 0, 0, stderr) >> >> which is undesireable. Instead instead of templates, we overload >> plain functions. This adds a small burden of manually adding >> the pointer version of dump for each type. Instead of default >> function arguments, we simply assume the default values. Most of >> the underlying dump functions did not use the options and indent >> parameters anyway. Several provide FILE* parameters, but we expect >> debugging to use stderr anyway. So, the explicit specification of >> arguments was not as valuable as we thought initially. > > Note that generally modules should provide a > > print_FOO (FILE *, FOO *...) > > interface which should be the worker for the dump_* interface > which prints to dumpfiles (and stdout/stderr with -fopt-info) and > the debug_* interface (which just prints to stderr).
I'm not sure what you're saying here. I haven't been adding new underlying functionality. If there are missing print_FOO functions, shouldn't they be a separate work item? >> Finally, a change of name from dump to debug reflect the implicit >> output to stderr. > > A few more questions. As we are now using C++ and these > functions are not called by GCC itself - do we really need > all the extern declarations in the header files? We don't have > -Wstrict-prototypes issues with C++ and I do not consider the debug > () interface part of the public API of a module. This avoids > people ending up calling debug () from inside GCC. We don't need the extern declarations for gdb, but I've written temporary calls to debug into the source code while I was developing. It would be handy to not have to add declarations simultaneously. Your call. > + if (ptr) > + debug (*ptr); > + else > + fprintf (stderr, "<nil>\n"); > > can we avoid repeating this using a common helper? I'd use a simple > #define like > > #define DO_DEBUG_PTR(p) do { if (p) debug (*(p)) else fprintf (stderr, > "<nil>\n"); } while (0) > > but I suppose you can come up with something more clever using C++? I had a template that did this for us in my earlier code. I removed the template when I discovered the gdb issue. One advantage to removing the template was that I no longer needed a common header and its inclusion in various files. Adding the macro would reintroduce the header. My personal preference is to avoid the macros and just live with the repeated pattern. -- Lawrence Crowl