From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9505 invoked by alias); 10 Dec 2012 21:03:05 -0000 Received: (qmail 9494 invoked by uid 22791); 10 Dec 2012 21:03:04 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,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; Mon, 10 Dec 2012 21:02:58 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBAL2v12031819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 10 Dec 2012 16:02:57 -0500 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBAL2uN7003909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 10 Dec 2012 16:02:57 -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> Date: Mon, 10 Dec 2012 21:03:00 -0000 In-Reply-To: <50C1F56E.5060506@redhat.com> (Phil Muldoon's message of "Fri, 07 Dec 2012 13:55:58 +0000") Message-ID: <87sj7dd3i7.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.90 (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: 2012-12/txt/msg00281.txt.bz2 >>>>> "Phil" == Phil Muldoon writes: Tom> I'd prefer it if the various callers were changed to use mi_getopt. Tom> This provides uniformity and lets us add options later. Phil> If there was uniformity then I would agree, but as far as I looked Phil> there wasn't. Some MI commands use mi_getopt, some parse their own Phil> options, some allow long options ("--"), others do not, and mi_getopt Phil> does not handle long options in any case (and huge amounts of other Phil> useful getopt functions too). I wrote a patch for mi_getopts to Phil> handle long options, but why do we even need another implementation of Phil> getopt like functionality? Ok, I see the problem now. Right now, though. -stack-list-frames doesn't take any options. I think it would be better if commands like this were converted to use mi_getopt instead of doing the parsing by hand. So I suggest having all the functions use a short option name. I think the changes like in -stack-list-locals are strange, too, in that they make options order-dependent. This will be surprising to users. Phil> I wanted to mention something else about MI. I recently discovered in Phil> the GDB manual that -stack-list-locals, -stack-list-arguments are Phil> considered depreciated. Not even sure if we should add frame filter Phil> logic to them. What do you think? I think we still ought to. It doesn't seem like much work and it is friendlier in case some MI user hasn't updated. Tom> I don't think I follow the high/low logic here. 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. Tom