From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28361 invoked by alias); 20 Feb 2013 20:37:35 -0000 Received: (qmail 28230 invoked by uid 22791); 20 Feb 2013 20:37:33 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Feb 2013 20:37:19 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1KKbJHB021781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Feb 2013 15:37:19 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1KKbHLY010526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 15:37:18 -0500 From: Tom Tromey To: Phil Muldoon Cc: "gdb-patches\@sourceware.org" Subject: Re: [patch][python] 2 of 5 - Frame filter MI code changes. References: <50B8C333.4070008@redhat.com> <87ip8gtoex.fsf@fleche.redhat.com> <50C1F56E.5060506@redhat.com> <87sj7dd3i7.fsf@fleche.redhat.com> <5124E8EB.10009@redhat.com> Date: Wed, 20 Feb 2013 20:37:00 -0000 In-Reply-To: <5124E8EB.10009@redhat.com> (Phil Muldoon's message of "Wed, 20 Feb 2013 15:16:59 +0000") Message-ID: <874nh6en7m.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00544.txt.bz2 >>>>> "Phil" == Phil Muldoon 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