From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4566 invoked by alias); 2 Dec 2013 16:10:37 -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 4554 invoked by uid 89); 2 Dec 2013 16:10:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 02 Dec 2013 16:10:35 +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 rB2GARr6005775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Dec 2013 11:10:28 -0500 Received: from barimba (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB2GAQcA021256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Dec 2013 11:10:27 -0500 From: Tom Tromey To: Pedro Alves Cc: 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> Date: Mon, 02 Dec 2013 16:10:00 -0000 In-Reply-To: <1385664356-29726-1-git-send-email-palves@redhat.com> (Pedro Alves's message of "Thu, 28 Nov 2013 18:45:56 +0000") Message-ID: <871u1vw7wt.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-12/txt/msg00041.txt.bz2 >>>>> "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. Tom