On Wed, Mar 27, 2013 at 5:15 PM, Lawrence Crowl <cr...@googlers.com> wrote:
> 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?
Sure. I just wanted to mention naming / semantics convention where
you mentioned FILE parameters.
>>> 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.
Ah, I see. I have no strong preference here.
>> + 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.
Ok, fine with me - I just wanted to double-check.
The patch is ok as-is.
Richard.
> --
> Lawrence Crowl
