[patch] Unified debug dump function names.

Lawrence Crowl crowl@googlers.com
Wed Mar 27 16:15:00 GMT 2013

On 3/27/13, Richard Biener <richard.guenther@gmail.com> wrote:
> On Mar 27, 2013, Lawrence Crowl <crowl@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

More information about the Gcc-patches mailing list