From: Tom Tromey <tromey@redhat.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch][python] 2 of 5 - Frame filter MI code changes.
Date: Wed, 20 Feb 2013 20:37:00 -0000 [thread overview]
Message-ID: <874nh6en7m.fsf@fleche.redhat.com> (raw)
In-Reply-To: <5124E8EB.10009@redhat.com> (Phil Muldoon's message of "Wed, 20 Feb 2013 15:16:59 +0000")
>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
Phil> So if the MI client, say in -stack-list-frames, asks for frames 0 - 3
Phil> the output would be:
Phil> 0
Phil> 1
Phil> 2
Phil> 3
Phil> 4
Phil> 5
Phil> 6
Phil> Because frame three has elided the next three frames -- it has to show
Phil> them to be consistent. One side result of this is we have dispatched
Phil> to the my client seven frames instead of four frames.
I think that frames 4-6 should be children of frame 3.
So there will still be just 4 "top-level" frames.
It's been a while so perhaps I'm not remembering the approach properly.
Phil> One side effect is now the frame levels don't match up to the frames
Phil> levels requested. Is this going to be a big issue for MI clients?
The main problem I can think of is that the MI client will expect to be
able to use the frame's id to select a frame. We have to ensure this
works ok.
For anything else I think MI clients can adapt.
Phil> The other issue is now frame filters, regardless of what slice is
Phil> asked form has to process the whole stack (whereas before they just
Phil> started on frame_low of the requested stack). This is because we have
Phil> to account for elided frames, and the consistency of output you noted
Phil> in your example (so even though we want frames 4 - 9, we still have to
Phil> start from frame 0, to see what has been elided before we get to our
Phil> slice). This has a performance issues associated with for large
Phil> backtraces.
Correctness has to come first.
I guess it might be possible to ensure that we always start processing
on an appropriate boundary, perhaps by constraining the MI client to do
so. This seems tricky though. And, it seems like something we could
add later if we find we really need it.
Tom
next prev parent reply other threads:[~2013-02-20 20:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 14:31 Phil Muldoon
2012-12-05 17:11 ` Tom Tromey
2012-12-07 13:56 ` Phil Muldoon
2012-12-10 21:03 ` Tom Tromey
2013-02-05 12:08 ` Phil Muldoon
2013-02-07 21:32 ` Tom Tromey
2013-02-20 15:17 ` Phil Muldoon
2013-02-20 20:37 ` Tom Tromey [this message]
2013-03-11 22:13 Phil Muldoon
2013-03-12 20:43 ` Tom Tromey
2013-03-12 20:52 ` Phil Muldoon
2013-03-13 12:15 ` Phil Muldoon
2013-03-13 17:48 ` Tom Tromey
2013-03-13 19:41 ` Phil Muldoon
2013-03-13 20:27 ` Tom Tromey
2013-03-13 20:53 ` Phil Muldoon
2013-03-13 20:56 ` Tom Tromey
2013-03-13 21:10 ` Phil Muldoon
2013-03-14 17:54 ` Tom Tromey
2013-03-14 19:35 ` Phil Muldoon
2013-04-22 16:01 Phil Muldoon
2013-04-26 11:19 ` Tom Tromey
2013-05-06 8:23 Phil Muldoon
2013-05-06 20:42 ` Tom Tromey
2013-05-07 8:23 ` Phil Muldoon
2013-05-07 14:02 ` Tom Tromey
2013-05-08 10:18 ` Phil Muldoon
2013-05-08 19:47 ` Tom Tromey
2013-05-10 10:45 ` Phil Muldoon
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=874nh6en7m.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=pmuldoon@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