From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16538 invoked by alias); 12 Dec 2013 17:37:10 -0000 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 Received: (qmail 16526 invoked by uid 89); 12 Dec 2013 17:37:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Dec 2013 17:37:09 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBCHb75U020647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Dec 2013 12:37:07 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rBCHb6j2023179; Thu, 12 Dec 2013 12:37:06 -0500 Message-ID: <52A9F441.20801@redhat.com> Date: Thu, 12 Dec 2013 17:37:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 CC: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC] Python's gdb.FRAME_UNWIND_NULL_ID is no longer used. What to do with it? References: <1385664356-29726-1-git-send-email-palves@redhat.com> <871u1vw7wt.fsf@fleche.redhat.com> <52A9F173.2010304@redhat.com> In-Reply-To: <52A9F173.2010304@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00507.txt.bz2 On 12/12/2013 05:25 PM, Pedro Alves wrote: > On 12/02/2013 04:10 PM, Tom Tromey wrote: >>>>>>> "Pedro" == Pedro Alves writes: >> >> Pedro> I'd assume scripts just check the result of Frame.unwind_stop_reason, >> Pedro> and compare it to gdb.FRAME_UNWIND_NO_REASON. That at most, they'll >> Pedro> pass the result of Frame.unwind_stop_reason to >> Pedro> gdb.frame_stop_reason_string. I'd prefer to just get rid of it, but >> Pedro> it may be best to keep this around for compatibility, in case a script >> Pedro> does refer to gdb.FRAME_UNWIND_NULL_ID directly. >> >> Pedro> In general, what's the policy for exposed constants like this in >> Pedro> Python? >> >> My view is that we should provide compatibility with what we document. >> >> That is, if it is in the docs, we should not remove it. >> >> However, there is still some leeway for change. >> E.g., in this case, we don't document the value or type of the constant. >> This is intentional as it gives us some freedom to change the details -- >> we don't generally want Python API promises to leak through to the C >> code. >> >> Pedro> +/* This is no longer used anywhere, but it's kept because it's exposed >> Pedro> + to Python. This is how GDB used to indicate end of stack. We've >> Pedro> + now migrated to a model where frames always have a valid ID. */ >> Pedro> SET (UNWIND_NULL_ID, "unwinder did not report frame ID") >> >> For example you could remove this, and arrange to keep the Python >> constant around with some suitably chosen value. I think it just has to >> be something that will never compare equal to any of the other >> constants, so just None would work. > > I tried that, and then I remembered to try frame_stop_reason_string > on it: > > (top-gdb) python print gdb.FRAME_UNWIND_NULL_ID > None > (top-gdb) python print gdb.FRAME_UNWIND_OUTERMOST > 1 > (top-gdb) python print gdb.frame_stop_reason_string(gdb.FRAME_UNWIND_OUTERMOST) > outermost > (top-gdb) python print gdb.frame_stop_reason_string(gdb.FRAME_UNWIND_NULL_ID) > Traceback (most recent call last): > File "", line 1, in > TypeError: an integer is required > Error while executing Python code. > > GDB itself won't ever generate FRAME_UNWIND_NULL_ID. Do think > that's a problem? I guess we could set it to UNWIND_LAST+1 > instead, and make gdbpy_frame_stop_reason_string handle it, > but at that point, I get to consider just leaving things > alone... > > Hmm, or perhaps, we could implement this another way. Leave > UNWIND_NULL_ID in unwind_stop_reasons.def, but define it > with a DEPRECATED_SET macro instead. I guess that might > actually be better considering multiple extension languages > going forward, as then we have a single place to do this, > instead of having to repeat the "create deprecated constant" > exercise for all extension languages whenever something like > this happens. Well, I tried that, but the result doesn't look that much better to me. I'm not really motivated to handle this right now, so I'll just forget about it for now. (others do please feel free to carry on. I do believe we'll end up needing to set some precedent.) -- Pedro Alves