This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb bugs showing while working on libcwd


On Mon, May 27, 2002 at 02:42:20PM +0200, Carlo Wood wrote:
> On Mon, May 27, 2002 at 02:03:29AM -0400, Daniel Jacobowitz wrote:
> > Of course it is; it's in a namespace.  Really, I don't expect any of
> > what you're doing to work right now.  My first stab at fixing it was a
> > complete disaster, too...
> 
> That would make sense if NOTHING worked that was in a namespace.
> But in many cases it does.  I trust you if think this is related
> to namespaces being unsupported, but never say 'of course'.
> 
> Because the whole standard resides in std::, this must be the
> reason that gdb is virtually unusable with C++ :/
> 
> (gdb) p result
> $2 = {static npos = Cannot access memory at address 0x8416bc4
> 
> (gdb) p buf
> $1 = {<basic_iostream<char,std::char_traits<char> >> = {<basic_istream<char,std::char_traits<char> >> =
> {<basic_ios<char,std::char_traits<char> >> = {<ios_base> = {static boolalpha = Cannot access memory at address 0x0
> 
> But if you ask me, it is more related to static members than
> to namespaces...

Here's my understanding:

For a lot of operations, we operate by looking up the demangled name in
a table of demanglings of the binary's symbols.  It may not behave
precisely right, because we lose some type information, but things
mostly work.  For some other operations, we try to behave correctly by
using the symbol table constructed from debug information; it's in that
latter case that we lose it.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]