Re: [patch] Unified debug dump function names.
On 3/28/13, Richard Biener wrote: > The patch is ok as-is. Committed. -- Lawrence Crowl
Re: [patch] Unified debug dump function names.
On Wed, Mar 27, 2013 at 5:15 PM, Lawrence Crowl wrote:
> On 3/27/13, Richard Biener wrote:
>> On Mar 27, 2013, Lawrence Crowl 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 '' 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, vec, vec,
>>> vec, vec,
>>>
>>> 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 (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, "\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,
>> "\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
Re: [patch] Unified debug dump function names.
On 3/27/13, Richard Biener wrote:
> On Mar 27, 2013, Lawrence Crowl 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 '' 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, vec, vec,
>> vec, vec,
>>
>> 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 (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, "\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,
> "\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
Re: [patch] Unified debug dump function names.
On Wed, Mar 27, 2013 at 12:50 AM, Lawrence Crowl wrote: > On 3/26/13, Lawrence Crowl wrote: >> On 3/26/13, Richard Biener wrote: >>> On Mar 25, 2013 Lawrence Crowl wrote: >>> > On 3/25/13, Richard Biener wrote: >>> > > You add a not used new interface. What for? >>> > >>> > So that people can use it. >>> > >>> > > For use from gdb only? >>> > >>> > No, for use from both gdb and internally. It is often that >>> > folks add dumps in various places while developing/debugging. >>> > These functions support that effort without having to hunt down >>> > the name. >>> >>> But having both interfaces is bad. As you are unconditionally >>> "dumping" to stderr using debug () is correct. Sorry that I >>> don't follow each and every proposal - nobody follows up my >>> proposals either. >>> >>> The dump_ namespace is claimed by dumping to dumpfiles and >>> diagnostics. >>> >>> > > In which case it should be debug (), not dump (). >>> > >>> > I will use whatever name you wish, but I would have preferred >>> > that we addressed naming issues when we published the plan, >>> > not after I've done the implementation. What name do you wish? >>> >>> debug (). >> >> Okay. >> >>> And I'd like you to remove the alternate debug_ interface that >>> is obsoleted by the overloads. >> >> I'm sure that folks have the old interfaces baked into scripts and >> dot files. I think it would should not remove the old interface >> until they have had some time to migrate. >> >>> Btw, the overloading will provide extra headache to one of the >>> most used ways to the debug_ routines: >>> >>> (gdb) call debug_tree (fndecl) >>> >>type >>type >>size >>>unit size >>>align 32 symtab 0 alias set -1 canonical type >>> 0x76d175e8 precision 32 min >> -2147483648> max >>> ... >>> (gdb) call debug_tree (0x76d175e8) >>> Cannot resolve function debug_tree to any overloaded instance >>> (gdb) call debug_tree >>> debug_tree(tree_node*) >>> debug_tree_chain(tree_node*) >>> debug_tree_chain(tree_node*)::__FUNCTION__ >>> debug_tree_ssa() >>> debug_tree_ssa_stats() >>> >>> (gdb) call debug_tree ((tree_node*)0x76d175e8) >>> >>size >> bitsizetype> constant 32> >>>unit size >> 0x76d17000 sizetype> constant 4> >>>align 32 symtab 0 alias set -1 canonical type 0x76d175e8 >>> precision 32 min max >>> >>>pointer_to_this > >>> >>> but with debug () having overloads to each and every thing we'd >>> ever want to debug the list of possible types I have to cast that >>> literal address I cut&pasted will be endless. >>> >>> Any suggestion on how to improve this situation? Yes, it's already >>> bad as with typing debug_tree I know it's a tree I am interested >>> in and >>> >>> (gdb) call debug_ >>> ... endless list of functions and overloads ... >>> >>> is probably as useless as >>> >>> (gdb) call debug >>> >>> is after your patch. >> >> I have three suggestions, in increasing order of difficulty. >> >> First, modify the dumpers to print the type cast in front of >> the hex value. The cut and paste is just a bit wider. >> >> Second, modify the dumpers to print the access expression (which >> would then not require the hex value). I'm not actually sure how >> well this would work in practice. It's a thought. >> >> Third, modify gdb to have an interactive data explorer. As a >> straw man, "explorer foo" would open up a window with all of >> foo's elements. Each pointer is clickable and changes your view to >> its referrent. I've used such a tool, and while it was sometimes >> at too low a level of abstraction, it was generally quite handy >> for exploring the data. In retrospect, it would be nice to fold >> sub-objects (in the editor sense). > > 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 '' 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, > >
Re: [patch] Unified debug dump function names.
On 3/26/13, Lawrence Crowl wrote: > On 3/26/13, Richard Biener wrote: >> On Mar 25, 2013 Lawrence Crowl wrote: >> > On 3/25/13, Richard Biener wrote: >> > > You add a not used new interface. What for? >> > >> > So that people can use it. >> > >> > > For use from gdb only? >> > >> > No, for use from both gdb and internally. It is often that >> > folks add dumps in various places while developing/debugging. >> > These functions support that effort without having to hunt down >> > the name. >> >> But having both interfaces is bad. As you are unconditionally >> "dumping" to stderr using debug () is correct. Sorry that I >> don't follow each and every proposal - nobody follows up my >> proposals either. >> >> The dump_ namespace is claimed by dumping to dumpfiles and >> diagnostics. >> >> > > In which case it should be debug (), not dump (). >> > >> > I will use whatever name you wish, but I would have preferred >> > that we addressed naming issues when we published the plan, >> > not after I've done the implementation. What name do you wish? >> >> debug (). > > Okay. > >> And I'd like you to remove the alternate debug_ interface that >> is obsoleted by the overloads. > > I'm sure that folks have the old interfaces baked into scripts and > dot files. I think it would should not remove the old interface > until they have had some time to migrate. > >> Btw, the overloading will provide extra headache to one of the >> most used ways to the debug_ routines: >> >> (gdb) call debug_tree (fndecl) >> >type >type >size >>unit size >>align 32 symtab 0 alias set -1 canonical type >> 0x76d175e8 precision 32 min > -2147483648> max >> ... >> (gdb) call debug_tree (0x76d175e8) >> Cannot resolve function debug_tree to any overloaded instance >> (gdb) call debug_tree >> debug_tree(tree_node*) >> debug_tree_chain(tree_node*) >> debug_tree_chain(tree_node*)::__FUNCTION__ >> debug_tree_ssa() >> debug_tree_ssa_stats() >> >> (gdb) call debug_tree ((tree_node*)0x76d175e8) >> >size > bitsizetype> constant 32> >>unit size > 0x76d17000 sizetype> constant 4> >>align 32 symtab 0 alias set -1 canonical type 0x76d175e8 >> precision 32 min max >> >>pointer_to_this > >> >> but with debug () having overloads to each and every thing we'd >> ever want to debug the list of possible types I have to cast that >> literal address I cut&pasted will be endless. >> >> Any suggestion on how to improve this situation? Yes, it's already >> bad as with typing debug_tree I know it's a tree I am interested >> in and >> >> (gdb) call debug_ >> ... endless list of functions and overloads ... >> >> is probably as useless as >> >> (gdb) call debug >> >> is after your patch. > > I have three suggestions, in increasing order of difficulty. > > First, modify the dumpers to print the type cast in front of > the hex value. The cut and paste is just a bit wider. > > Second, modify the dumpers to print the access expression (which > would then not require the hex value). I'm not actually sure how > well this would work in practice. It's a thought. > > Third, modify gdb to have an interactive data explorer. As a > straw man, "explorer foo" would open up a window with all of > foo's elements. Each pointer is clickable and changes your view to > its referrent. I've used such a tool, and while it was sometimes > at too low a level of abstraction, it was generally quite handy > for exploring the data. In retrospect, it would be nice to fold > sub-objects (in the editor sense). 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 '' 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, vec, vec, vec, vec, 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 somewha
Re: [patch] Unified debug dump function names.
On 3/26/13, Richard Biener wrote: > On Mar 25, 2013 Lawrence Crowl wrote: > > On 3/25/13, Richard Biener wrote: > > > You add a not used new interface. What for? > > > > So that people can use it. > > > > > For use from gdb only? > > > > No, for use from both gdb and internally. It is often that > > folks add dumps in various places while developing/debugging. > > These functions support that effort without having to hunt down > > the name. > > But having both interfaces is bad. As you are unconditionally > "dumping" to stderr using debug () is correct. Sorry that I > don't follow each and every proposal - nobody follows up my > proposals either. > > The dump_ namespace is claimed by dumping to dumpfiles and > diagnostics. > > > > In which case it should be debug (), not dump (). > > > > I will use whatever name you wish, but I would have preferred > > that we addressed naming issues when we published the plan, > > not after I've done the implementation. What name do you wish? > > debug (). Okay. > And I'd like you to remove the alternate debug_ interface that > is obsoleted by the overloads. I'm sure that folks have the old interfaces baked into scripts and dot files. I think it would should not remove the old interface until they have had some time to migrate. > Btw, the overloading will provide extra headache to one of the > most used ways to the debug_ routines: > > (gdb) call debug_tree (fndecl) > type type size >unit size >align 32 symtab 0 alias set -1 canonical type > 0x76d175e8 precision 32 min -2147483648> max > ... > (gdb) call debug_tree (0x76d175e8) > Cannot resolve function debug_tree to any overloaded instance > (gdb) call debug_tree > debug_tree(tree_node*) > debug_tree_chain(tree_node*) > debug_tree_chain(tree_node*)::__FUNCTION__ > debug_tree_ssa() > debug_tree_ssa_stats() > > (gdb) call debug_tree ((tree_node*)0x76d175e8) > size bitsizetype> constant 32> >unit size 0x76d17000 sizetype> constant 4> >align 32 symtab 0 alias set -1 canonical type 0x76d175e8 > precision 32 min max > >pointer_to_this > > > but with debug () having overloads to each and every thing we'd > ever want to debug the list of possible types I have to cast that > literal address I cut&pasted will be endless. > > Any suggestion on how to improve this situation? Yes, it's already > bad as with typing debug_tree I know it's a tree I am interested > in and > > (gdb) call debug_ > ... endless list of functions and overloads ... > > is probably as useless as > > (gdb) call debug > > is after your patch. I have three suggestions, in increasing order of difficulty. First, modify the dumpers to print the type cast in front of the hex value. The cut and paste is just a bit wider. Second, modify the dumpers to print the access expression (which would then not require the hex value). I'm not actually sure how well this would work in practice. It's a thought. Third, modify gdb to have an interactive data explorer. As a straw man, "explorer foo" would open up a window with all of foo's elements. Each pointer is clickable and changes your view to its referrent. I've used such a tool, and while it was sometimes at too low a level of abstraction, it was generally quite handy for exploring the data. In retrospect, it would be nice to fold sub-objects (in the editor sense). -- Lawrence Crowl
Re: [patch] Unified debug dump function names.
On Mon, Mar 25, 2013 at 6:19 PM, Lawrence Crowl wrote: > On 3/25/13, Richard Biener wrote: >> You add a not used new interface. What for? > > So that people can use it. > >> For use from gdb only? > > No, for use from both gdb and internally. It is often that folks add > dumps in various places while developing/debugging. These functions > support that effort without having to hunt down the name. But having both interfaces is bad. As you are unconditionally "dumping" to stderr using debug () is correct. Sorry that I don't follow each and every proposal - nobody follows up my proposals either. The dump_ namespace is claimed by dumping to dumpfiles and diagnostics. >> In which case it should be debug (), not dump (). > > I will use whatever name you wish, but I would have preferred that > we addressed naming issues when we published the plan, not after > I've done the implementation. What name do you wish? debug (). And I'd like you to remove the alternate debug_ interface that is obsoleted by the overloads. Btw, the overloading will provide extra headache to one of the most used ways to the debug_ routines: (gdb) call debug_tree (fndecl) unit size align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min max ... (gdb) call debug_tree (0x76d175e8) Cannot resolve function debug_tree to any overloaded instance (gdb) call debug_tree debug_tree(tree_node*) debug_tree_chain(tree_node*) debug_tree_chain(tree_node*)::__FUNCTION__ debug_tree_ssa() debug_tree_ssa_stats() (gdb) call debug_tree ((tree_node*)0x76d175e8) constant 32> unit size constant 4> align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min max pointer_to_this > but with debug () having overloads to each and every thing we'd ever want to debug the list of possible types I have to cast that literal address I cut&pasted will be endless. Any suggestion on how to improve this situation? Yes, it's already bad as with typing debug_tree I know it's a tree I am interested in and (gdb) call debug_ ... endless list of functions and overloads ... is probably as useless as (gdb) call debug is after your patch. Thanks, Richard. > -- > Lawrence Crowl
Re: [patch] Unified debug dump function names.
> "Lawrence" == Lawrence Crowl writes:
Lawrence> My model is that I should be able to cut and paste an expression
Lawrence> from the source to the debugger and have it work. I concede that
Lawrence> C++ function overload resolution is a hard problem. However, gdb
Lawrence> has a slightly easier task in that it won't be doing instantiation
Lawrence> (as that expression has already instantiated everything it needs)
Lawrence> and so it need only pick among what exists.
Yeah, what isn't clear to me is that even this can be done in a
behavior-preserving way, at least short of having full source available
and the entire compiler in the debugger.
I'd be very pleased to be wrong, but my current understanding is that
one can play arbitrary games with SFINAE to come up with code that
defeats any less complete solution.
Sergio is going to look at this area again. So if you know differently,
it would be great to have your input.
I can dig up the current ("pending" -- but really unreviewed for a few
years for the above reasons) gdb patch if you are interested. I believe
it worked by applying overload-resolution-like rules to templates
(though it has been a while).
Tom
Re: [patch] Unified debug dump function names.
On 3/25/13, Tom Tromey wrote: >> "Lawrence" == Lawrence Crowl writes: > Lawrence> This patch is somewhat different from the original plan at > Lawrence> gcc.gnu.org/wiki/cxx-conversion/debugging-dumps. The reason > Lawrence> is that gdb has an incomplete implementation of C++ call syntax; > Lawrence> requiring explicit specification of template arguments and > Lawrence> explicit specification of function arguments even when they have > Lawrence> default values. > > Note that the latter is because GCC doesn't emit this information. I'm not laying blame anywhere, just informing folks of an adjustment to the plan due to the current situation. > As for the former ... we have a patch that works in some cases, > but it's actually unclear to me how well the debugger can do > in general here. We haven't put it in since it seems better to > require users to be explicit than to silently do the wrong thing > in some cases. My model is that I should be able to cut and paste an expression from the source to the debugger and have it work. I concede that C++ function overload resolution is a hard problem. However, gdb has a slightly easier task in that it won't be doing instantiation (as that expression has already instantiated everything it needs) and so it need only pick among what exists. -- Lawrence Crowl
Re: [patch] Unified debug dump function names.
On 3/25/13, Richard Biener wrote: > You add a not used new interface. What for? So that people can use it. > For use from gdb only? No, for use from both gdb and internally. It is often that folks add dumps in various places while developing/debugging. These functions support that effort without having to hunt down the name. > In which case it should be debug (), not dump (). I will use whatever name you wish, but I would have preferred that we addressed naming issues when we published the plan, not after I've done the implementation. What name do you wish? -- Lawrence Crowl
Re: [patch] Unified debug dump function names.
> "Lawrence" == Lawrence Crowl writes: Lawrence> This patch is somewhat different from the original plan at Lawrence> gcc.gnu.org/wiki/cxx-conversion/debugging-dumps. The reason Lawrence> is that gdb has an incomplete implementation of C++ call syntax; Lawrence> requiring explicit specification of template arguments and explicit Lawrence> specification of function arguments even when they have default Lawrence> values. Note that the latter is because GCC doesn't emit this information. As for the former ... we have a patch that works in some cases, but it's actually unclear to me how well the debugger can do in general here. We haven't put it in since it seems better to require users to be explicit than to silently do the wrong thing in some cases. Tom
