From: Vladimir Prus <ghost@cs.msu.su>
To: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
Subject: Re: [RFC] Prints the frame id when target stops
Date: Wed, 17 Jan 2007 21:46:00 -0000 [thread overview]
Message-ID: <E1H7Ibk-0006oa-CA@zigzag.lvk.cs.msu.su> (raw)
In-Reply-To: <20070117061815.GD19331@nevyn.them.org>
Daniel Jacobowitz wrote:
>> > It would change the behviour of those commands but I guess it could be
>> > added as an option.
>>
>> It actually won't. If -stack-list-frames is changed to return cached
>> result when it's absolutely clear that the stack did not change, you have
>> no behaviour change, just better performance.
>
> But Nick is right - it is very hard to determine whether two frames
> with the same frame ID are the same frame across an operation.
Yes. But:
1. We can regenerate stack frames list when not sure.
2. It's not easier for frontend than it is for gdb.
> It'd be
> nice if that weren't the case. The hard case for this is unfortunately
> very hard - but if the front end knows that it did a single step, then
> it's very unlikely to be wrong if the ID is unchanged.
Oh, if the frontend knows it did just a single "-exec-step", then
gdb knows it too.
> I really don't
> know what the right thing to do here is. Guessing based on what the
> last execution was (step, next, vs continue or C-c) might be the best
> we can do :-(
>
> Here's how it can happen:
>
> int foo()
> {
> return 1;
> }
>
> int bar()
> {
> char buf[SIZE1];
> return foo();
> }
>
> int bar2()
> {
> char buf[SIZE2];
> return foo();
> }
>
> int bar3()
> {
> char buf[SIZE3];
> return bar2();
> }
>
> int main()
> {
> bar();
> bar3();
> }
>
> The backtrace is different in an interesting way here if you set a
> breakpoint on foo and continue twice, but if you choose your buffer
> sizes just right, then you can get the two calls to foo to have the
> same ID. If your IDE doesn't refresh its stack display, you're
> going to have a stale call trace.
Yes, that's an obvious problem. What makes you think a frontend
is in better position to fix it?
> Apple implemented a very high performance, light weight unwinder that
> just does frame IDs - on PPC this happens to be quite easy. We could
> make other targets do the same thing. That probably helps here.
Just to clarify -- you mean you don't get any function names or
code lines so you don't have to look in the symbol tables? And
if this backtrace changes you can get the full backtrace.
- Volodya
next prev parent reply other threads:[~2007-01-17 21:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-15 16:21 Denis PILAT
2007-01-15 21:37 ` Nick Roberts
2007-01-15 23:11 ` Nick Roberts
2007-01-15 23:49 ` Nick Roberts
2007-01-17 8:26 ` Denis PILAT
2007-01-16 16:20 ` Vladimir Prus
2007-01-16 21:12 ` Nick Roberts
2007-01-16 23:38 ` Vladimir Prus
2007-01-17 6:18 ` Daniel Jacobowitz
2007-01-17 21:46 ` Vladimir Prus [this message]
2007-01-20 17:02 ` Daniel Jacobowitz
2007-01-17 21:29 ` Mark Kettenis
2007-01-17 21:38 ` Vladimir Prus
2007-01-17 21:59 ` Frédéric Riss
2007-01-17 22:14 ` Vladimir Prus
2007-01-18 8:00 ` Frederic RISS
2007-01-17 22:17 ` Daniel Jacobowitz
2007-01-18 7:58 ` Frederic RISS
2007-01-18 18:34 ` Jim Blandy
2007-01-19 14:28 ` Denis PILAT
2007-01-20 17:00 ` Daniel Jacobowitz
2007-01-18 19:59 ` Daniel Jacobowitz
2007-01-17 6:19 ` Daniel Jacobowitz
2007-01-18 21:13 ` Nick Roberts
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=E1H7Ibk-0006oa-CA@zigzag.lvk.cs.msu.su \
--to=ghost@cs.msu.su \
--cc=drow@false.org \
--cc=gdb-patches@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