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 0x7ffff6e1b900 foo > type <function_type 0x7ffff6d28c78 > type <integer_type 0x7ffff6d175e8 int public SI > size <integer_cst 0x7ffff6d1a0c0 constant 32> > unit size <integer_cst 0x7ffff6d1a0e0 constant 4> > align 32 symtab 0 alias set -1 canonical type > 0x7ffff6d175e8 precision 32 min <integer_cst 0x7ffff6d1a060 > -2147483648> max <integer_cst 0x7ffff6d1a080 2147483647> > ... > (gdb) call debug_tree (0x7ffff6d175e8) > Cannot resolve function debug_tree to any overloaded instance > (gdb) call debug_tree<tab><tab> > 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*)0x7ffff6d175e8) > <integer_type 0x7ffff6d175e8 int public SI > size <integer_cst 0x7ffff6d1a0c0 type <integer_type 0x7ffff6d170a8 > bitsizetype> constant 32> > unit size <integer_cst 0x7ffff6d1a0e0 type <integer_type > 0x7ffff6d17000 sizetype> constant 4> > align 32 symtab 0 alias set -1 canonical type 0x7ffff6d175e8 > precision 32 min <integer_cst 0x7ffff6d1a060 -2147483648> max > <integer_cst 0x7ffff6d1a080 2147483647> > pointer_to_this <pointer_type 0x7ffff6d1f2a0>> > > 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_<tab><tab> > ... endless list of functions and overloads ... > > is probably as useless as > > (gdb) call debug<tab><tab> > > 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
