Re: [patch] Unified debug dump function names.
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,
veccp_token, va_gc, vecdata_reference_p, vecddr_p,
vecrtx, vectree, 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
Re: [patch] Unified debug dump function names.
On 3/28/13, Richard Biener richard.guent...@gmail.com wrote: The patch is ok as-is. Committed. -- Lawrence Crowl
Re: [patch] Unified debug dump function names.
On Wed, Mar 27, 2013 at 12:50 AM, Lawrence Crowl cr...@googlers.com wrote: On 3/26/13, Lawrence Crowl cr...@googlers.com wrote: On 3/26/13, Richard Biener richard.guent...@gmail.com wrote: On Mar 25, 2013 Lawrence Crowl cr...@googlers.com wrote: On 3/25/13, Richard Biener richard.guent...@gmail.com 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) function_decl 0x76e1b900 foo type function_type 0x76d28c78 type integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 constant 32 unit size integer_cst 0x76d1a0e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 ... (gdb) call debug_tree (0x76d175e8) Cannot resolve function debug_tree to any overloaded instance (gdb) call debug_treetabtab debug_tree(tree_node*) debug_tree_chain(tree_node*) debug_tree_chain(tree_node*)::__FUNCTION__ debug_tree_ssa() debug_tree_ssa_stats() aha! (ok, I know this one is 'tree') (gdb) call debug_tree ((tree_node*)0x76d175e8) integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 type integer_type 0x76d170a8 bitsizetype constant 32 unit size integer_cst 0x76d1a0e0 type integer_type 0x76d17000 sizetype constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 pointer_to_this pointer_type 0x76d1f2a0 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 cutpasted 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_tabtab ... endless list of functions and overloads ... is probably as useless as (gdb) call debugtabtab 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 '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)
Re: [patch] Unified debug dump function names.
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,
veccp_token, va_gc, vecdata_reference_p, vecddr_p,
vecrtx, vectree, 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
Re: [patch] Unified debug dump function names.
On Mon, Mar 25, 2013 at 6:19 PM, Lawrence Crowl cr...@googlers.com wrote: On 3/25/13, Richard Biener richard.guent...@gmail.com 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) function_decl 0x76e1b900 foo type function_type 0x76d28c78 type integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 constant 32 unit size integer_cst 0x76d1a0e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 ... (gdb) call debug_tree (0x76d175e8) Cannot resolve function debug_tree to any overloaded instance (gdb) call debug_treetabtab debug_tree(tree_node*) debug_tree_chain(tree_node*) debug_tree_chain(tree_node*)::__FUNCTION__ debug_tree_ssa() debug_tree_ssa_stats() aha! (ok, I know this one is 'tree') (gdb) call debug_tree ((tree_node*)0x76d175e8) integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 type integer_type 0x76d170a8 bitsizetype constant 32 unit size integer_cst 0x76d1a0e0 type integer_type 0x76d17000 sizetype constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 pointer_to_this pointer_type 0x76d1f2a0 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 cutpasted 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_tabtab ... endless list of functions and overloads ... is probably as useless as (gdb) call debugtabtab is after your patch. Thanks, Richard. -- Lawrence Crowl
Re: [patch] Unified debug dump function names.
On 3/26/13, Richard Biener richard.guent...@gmail.com wrote: On Mar 25, 2013 Lawrence Crowl cr...@googlers.com wrote: On 3/25/13, Richard Biener richard.guent...@gmail.com 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) function_decl 0x76e1b900 foo type function_type 0x76d28c78 type integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 constant 32 unit size integer_cst 0x76d1a0e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 ... (gdb) call debug_tree (0x76d175e8) Cannot resolve function debug_tree to any overloaded instance (gdb) call debug_treetabtab debug_tree(tree_node*) debug_tree_chain(tree_node*) debug_tree_chain(tree_node*)::__FUNCTION__ debug_tree_ssa() debug_tree_ssa_stats() aha! (ok, I know this one is 'tree') (gdb) call debug_tree ((tree_node*)0x76d175e8) integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 type integer_type 0x76d170a8 bitsizetype constant 32 unit size integer_cst 0x76d1a0e0 type integer_type 0x76d17000 sizetype constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 pointer_to_this pointer_type 0x76d1f2a0 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 cutpasted 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_tabtab ... endless list of functions and overloads ... is probably as useless as (gdb) call debugtabtab 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 3/26/13, Lawrence Crowl cr...@googlers.com wrote: On 3/26/13, Richard Biener richard.guent...@gmail.com wrote: On Mar 25, 2013 Lawrence Crowl cr...@googlers.com wrote: On 3/25/13, Richard Biener richard.guent...@gmail.com 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) function_decl 0x76e1b900 foo type function_type 0x76d28c78 type integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 constant 32 unit size integer_cst 0x76d1a0e0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 ... (gdb) call debug_tree (0x76d175e8) Cannot resolve function debug_tree to any overloaded instance (gdb) call debug_treetabtab debug_tree(tree_node*) debug_tree_chain(tree_node*) debug_tree_chain(tree_node*)::__FUNCTION__ debug_tree_ssa() debug_tree_ssa_stats() aha! (ok, I know this one is 'tree') (gdb) call debug_tree ((tree_node*)0x76d175e8) integer_type 0x76d175e8 int public SI size integer_cst 0x76d1a0c0 type integer_type 0x76d170a8 bitsizetype constant 32 unit size integer_cst 0x76d1a0e0 type integer_type 0x76d17000 sizetype constant 4 align 32 symtab 0 alias set -1 canonical type 0x76d175e8 precision 32 min integer_cst 0x76d1a060 -2147483648 max integer_cst 0x76d1a080 2147483647 pointer_to_this pointer_type 0x76d1f2a0 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 cutpasted 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_tabtab ... endless list of functions and overloads ... is probably as useless as (gdb) call debugtabtab 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 '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,
Re: [patch] Unified debug dump function names.
Lawrence == Lawrence Crowl cr...@googlers.com 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
Re: [patch] Unified debug dump function names.
On 3/25/13, Richard Biener richard.guent...@gmail.com 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.
On 3/25/13, Tom Tromey tro...@redhat.com wrote: Lawrence == Lawrence Crowl cr...@googlers.com 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.
Lawrence == Lawrence Crowl cr...@googlers.com 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
