From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4793 invoked by alias); 20 Feb 2013 15:17:16 -0000 Received: (qmail 4773 invoked by uid 22791); 20 Feb 2013 15:17:15 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,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 15:17:02 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFH1Ju019752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Feb 2013 10:17:01 -0500 Received: from localhost.localdomain (ovpn-116-98.ams2.redhat.com [10.36.116.98]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1KFH0wo028256; Wed, 20 Feb 2013 10:17:00 -0500 Message-ID: <5124E8EB.10009@redhat.com> Date: Wed, 20 Feb 2013 15:17:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Tom Tromey 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> In-Reply-To: <87sj7dd3i7.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00533.txt.bz2 > Tom> How does this code strip off the first 'frame_low' frames? > > Phil> fi is unwound to the position of frame_low in a loop preceding this > Phil> call. This is existing code, and not in the patch context. > > Tom> Also, Do frame_low and frame_high refer to "raw" or "cooked" frames? > Tom> I tend to think they should refer to cooked ones, but I think at least > Tom> the answer should be explicit and documented. > > Phil> In the existing mi sense, they just refer to frames on the stack. I > Phil> followed this logic, but something I am still unsure of is if a frame > Phil> is elided between frame low, and frame high, if that should be > Phil> counted. I think it should. > > I see. I think this is wrong then. I think the arguments have to be > applied after filtering. Here's why: > > One use for these arguments to the stack commands is so that a GUI can > display just part of the stack, and then, if the user scrolls the > display, it can request more of the stack to show. This way the GUI > doesn't have to unwind the whole stack just to show the first 5 lines or > whatever. > > Suppose you have a frame filter that notices a sentinel frame and then > elides the following 3 frames. This isn't necessarily an obscure > situation, maybe some interpreter takes a few function calls to > implement a call in the interpreted language and the filter wants to > collapse those frames to just show what is happening in the interpreted > code. > > Suppose this sentinel frame occurs at stack position 3. > > Now suppose the MI client requests frames 0..4. Ok, the filter will > work (since it can request more frames than the MI client did) and will > present the right thing. > > But now the user scrolls the window and the MI client requests frames > starting at frame 5. > > Whoops -- the output will be inconsistent; the filter won't trigger > because the sentinel appears at frame 3, which the existing code already > iterated past. Ok I've adjusted in my local patch to align with your concerns, but I wanted to make sure that we on the same page, and explore some things that are a side result of this change. So take this stack trace, I'll just use frame levels here for illustrative purposes: 0 1 2 3 4 5 6 7 8 9 And in your example, we have a sentinel frame level 3, which elided three other frames. So now our backtrace looks like: 0 1 2 3 4 5 6 7 8 9 So if the MI client, say in -stack-list-frames, asks for frames 0 - 3 the output would be: 0 1 2 3 4 5 6 Because frame three has elided the next three frames -- it has to show them to be consistent. One side result of this is we have dispatched to the my client seven frames instead of four frames. This might be something the MI client is not expecting, but that is ok as you have to turn on frame filters explicitly in MI, and we can assume that if the client does that, they can know to expect this kind of behavior. The next example is the client asking for frames 4 - 9. The output will be 7 8 9 The client asked for 6 frames, but we delivered three. But that is ok, as we noted above. One side effect is now the frame levels don't match up to the frames levels requested. Is this going to be a big issue for MI clients? The other issue is now frame filters, regardless of what slice is asked form has to process the whole stack (whereas before they just started on frame_low of the requested stack). This is because we have to account for elided frames, and the consistency of output you noted in your example (so even though we want frames 4 - 9, we still have to start from frame 0, to see what has been elided before we get to our slice). This has a performance issues associated with for large backtraces. What do you think? Is this in line with your thoughts? Cheers, Phil