From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Jim Blandy Cc: Daniel Berlin , gdb@sources.redhat.com Subject: Re: More C++ debugging comments Date: Tue, 03 Jul 2001 12:48:00 -0000 Message-id: <87u20tdc9p.fsf@cgsoftware.com> References: <69231459.994101560@[192.168.0.106]> X-SW-Source: 2001-07/msg00013.html Jim Blandy writes: > Daniel Berlin writes: >> However, it would require significant rework of the debugger to support it. >> And some compiler work too. > > Can Dwarf2.1 carry the necessary information? Yes. Easily. > > I'm happy to rework the debugger's symbol tables as needed to make > this stuff work. But we need the right info from the compiler > first. You do, of course, realize that the reason the compiler has been waiting to emit the right info is because the debugger hasn't supported it yet. It's a vicious cycle. Unless it's the same person doing the work on both side, people tend to either miss that the compiler is waiting on the debugger, or vice versa. We need some sort of official liasion or something. Or maybe something that is subscribed to gcc-cvs, that when it receives a commit message on *out.c (dbxout,dwarf2out,etc), forwards it to a gdb list. Considering how often these files are touched, and the fact that the files *only* concern debug output, I don't think false positives would be an issue. Of course, this would only tell us when gcc has already changed, not what hasn't been implemented because someone was waiting for the debugger to do it. > >> I can create symbols for namespaces if it helps, too (We always get these >> "no symbol named "A" in current context" where A is a namespace, since >> symbols don't exist for them). > > The more information, the better, I'd say. Okeydokey. -- "Curiosity killed the cat, but for a while I was a suspect. "-Steven Wright