Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Peter Thompson/Amy Kirschner <amypeter@rcn.com>
Cc: gdb@sources.redhat.com
Subject: Re: Is c++ debugging really "this" bad?
Date: Mon, 29 Jul 2002 20:03:00 -0000	[thread overview]
Message-ID: <20020730030315.GA15295@nevyn.them.org> (raw)
In-Reply-To: <3D46008C.DCD89FAF@rcn.com>

On Mon, Jul 29, 2002 at 10:57:16PM -0400, Peter Thompson/Amy Kirschner wrote:
> I'm doing some contract work helping a small company with their tool
> issues and have run across a nasty c++/gdb interaction.  I've been
> checking the archives and I find some related bugs in the c++ area, but
> not the specific issue I'm running into.
> 
> The basic problem.  Printing the value of 'this', the c++ object
> pointer, does not agree with a simple printf of 'this' in the same
> routine.  The particular routine I'm looking at is a destructor routine,
> and I have seen reasonable values of 'this' in other routines, but the
> wrong behavior seems to occur more often.  Or maybe just gets reported
> to me more often...
> 
> Some details:  We're using the 3.0.1 version of gcc and gdb with a mips
> 32 instruction set.  We do have a version of 3.0.4 available, but have
> not done extensive testing with that.  Gdb first looks for a local
> variable, $this, but doesn't find it in the current scope, or any
> containing scope.  Then it attempts to find 'this' in the local scope,
> and, failing that, looks to the outer scope where it does eventually
> find a 'this' variable, which is of course totally unrelated.  Our
> standard compilation options are (among a variety of others) -g and -O1.
> I've tried -g -O0, -g by itself (pretty much the same, eh?), -g3 -O1,
> and while -O0 produces a local copy of 'this', it still doesn't find the
> right value.  The gcc compiler I'm using produces a .mdebug section,
> which contains ecoff data, and does not recognize a -gdwarf or -gdwarf-2
> option.
> 
> I keep getting the feeling that maybe I'm just missing something basic,
> or the debugger is.  Certainly the compiler knows where the real value
> is, and I can track it via the machine code for any line that
> manipulates 'this', but I don't expect all the users to be able to do
> that readily.  Does this ring any bells with anyone?

I've never specifically seen the debugger lose track of 'this' in
destructors, but I haven't tried in a little while.

With GCC 3.0.1 (and mdebug to boot) you can't really expect C++
debugging to work.  The required changes for stabs debugging of C++
code are only in later releases; I think 3.0.4 was fixed but I'm not
sure.  Use 3.1.1 if possible.  That will require a matching binutils
upgrade.

You didn't mention what version of GDB you were using, also.

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


  reply	other threads:[~2002-07-30  3:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-29 19:56 Peter Thompson/Amy Kirschner
2002-07-29 20:03 ` Daniel Jacobowitz [this message]
2002-07-29 21:25   ` Peter Thompson/Amy Kirschner

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=20020730030315.GA15295@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=amypeter@rcn.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