From: Nick Roberts <nickrob@snap.net.nz>
To: Maxim Grigoriev <maxim@tensilica.com>
Cc: Daniel Jacobowitz <drow@false.org>,
gdb@sourceware.org, Pete MacLiesh <pmac@tensilica.com>,
Vinay Pandit <vinayp@tensilica.com>,
Shaiju P <shaijup@tensilica.com>,
Marc Gauthier <marc@tensilica.com>
Subject: Re: Which MI behavior is correct ?
Date: Sat, 19 May 2007 23:08:00 -0000 [thread overview]
Message-ID: <17999.33661.331676.464061@kahikatea.snap.net.nz> (raw)
In-Reply-To: <464F51B5.5040802@hq.tensilica.com>
> > Aren't the variables associated with a particular frame ID? I thought
> > we'd decided that it was the right thing to take them out of scope.
>
> This seems to be an answer to my question. The behavior has changed
> probably since somewhere around 6.3. Now, variable objects are associated
> with the frame, not with the function. As you can see in gdb 6.3 case
> ( NATIVE.log ), variables "var1" and "var2" were successfully reused,
> when new frame was allocated after hitting the breakpoint second time.
> In 6.5+ (XTENSA.log), we have to recreate variable objects every time
> we have a new frame because the old variables are out of scope.
As I said last time, I get the gdb 6.3 behaviour with FSF GDB 6.5. In fact
I can't see how GDB can take the variables out of scope when the stack
address and code address are the same.
> Correct ?
>
> How about efficiency ? What if we have to create hundreds of variable
> objects at every breakpoint hit ?
>
> We kept staying with GNU gdb 5.2.1 for too long. So it looks like
> we might have missed this important change, which is already in the
> past for the majority of GNU gdb users.
I still think you're barking up the wrong tree. Can't you test a stock
GDB 6.5 somewhere to see which behaviour you get? If it has changed can
you identify when it did from the ChangeLog?
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2007-05-19 23:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-19 1:01 Maxim Grigoriev
2007-05-19 1:58 ` Maxim Grigoriev
2007-05-19 2:20 ` Nick Roberts
2007-05-19 3:03 ` Daniel Jacobowitz
2007-05-19 3:27 ` Nick Roberts
2007-05-19 19:36 ` Maxim Grigoriev
2007-05-19 23:08 ` Nick Roberts [this message]
2007-05-21 3:43 ` Maxim Grigoriev
2007-05-25 20:51 ` Jim Blandy
2007-05-25 21:48 ` Maxim Grigoriev
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=17999.33661.331676.464061@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=drow@false.org \
--cc=gdb@sourceware.org \
--cc=marc@tensilica.com \
--cc=maxim@tensilica.com \
--cc=pmac@tensilica.com \
--cc=shaijup@tensilica.com \
--cc=vinayp@tensilica.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