From: Daniel Jacobowitz <drow@mvista.com>
To: Carlo Wood <carlo@alinoe.com>
Cc: gdb@sources.redhat.com
Subject: Re: gdb bugs showing while working on libcwd
Date: Mon, 27 May 2002 11:05:00 -0000 [thread overview]
Message-ID: <20020527180451.GA5523@branoic.them.org> (raw)
In-Reply-To: <20020527144220.A16085@alinoe.com>
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
next prev parent reply other threads:[~2002-05-27 18:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020522115242.C28512@redhat.com>
[not found] ` <20020523153816.A4454@alinoe.com>
[not found] ` <20020523094527.B25730@redhat.com>
2002-05-23 17:35 ` Carlo Wood
2002-05-23 18:58 ` Daniel Jacobowitz
2002-05-24 8:41 ` Huge problems with debugging threaded C++ programs Liam Stewart
2002-05-24 9:42 ` gdb bugs showing while working on libcwd Carlo Wood
2002-05-24 18:33 ` Carlo Wood
2002-05-24 18:41 ` Daniel Jacobowitz
2002-05-26 18:43 ` Carlo Wood
2002-05-26 23:03 ` Daniel Jacobowitz
2002-05-27 5:42 ` Carlo Wood
2002-05-27 11:05 ` Daniel Jacobowitz [this message]
2002-05-27 17:01 ` Carlo Wood
2002-05-28 1:17 ` Daniel Jacobowitz
2002-05-28 5:50 ` Carlo Wood
2002-05-28 10:37 ` Daniel Jacobowitz
2002-05-28 15:54 ` Carlo Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020527180451.GA5523@branoic.them.org \
--to=drow@mvista.com \
--cc=carlo@alinoe.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox