From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35628 invoked by alias); 19 Feb 2019 00:57:24 -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 35613 invoked by uid 89); 19 Feb 2019 00:57:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy= 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; Tue, 19 Feb 2019 00:57:22 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2696C59464; Tue, 19 Feb 2019 00:57:21 +0000 (UTC) Received: from f29-4.lan (ovpn-117-11.phx2.redhat.com [10.3.117.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB3315ED4B; Tue, 19 Feb 2019 00:57:20 +0000 (UTC) Date: Tue, 19 Feb 2019 00:57:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH 2/4] Define gdb.Value(bufobj, type) constructor Message-ID: <20190218175720.6cf45742@f29-4.lan> In-Reply-To: <87h8d0lnq2.fsf@tromey.com> References: <20190218075816.6f67f3d9@f29-4.lan> <20190218080636.02e3847f@f29-4.lan> <87h8d0lnq2.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00296.txt.bz2 On Mon, 18 Feb 2019 15:45:57 -0700 Tom Tromey wrote: > >>>>> "Kevin" == Kevin Buettner writes: > > FWIW I think this whole series looks quite reasonable and would be a > good addition. Thanks for looking it over. > Kevin> + Py_buffer py_buf; > > Elsewhere in the Python code, Py_buffer is only used conditionally on > "#ifdef IS_PY3K". I don't know exactly why, though. Py_buffer seems to > be in Python 2.7, maybe it wasn't in some earlier version that gdb still > supports? FWIW, I've tested my patch using both Python 2.7 and Python 3.7, which are what I have on my F29 machine. > I don't know whether anyone still relies on older versions of Python > (2.7 was released in 2010 so it seems plenty old at this point; after > all we require compilers released after this). > > However, this seems like a decision to make consciously. > I'm not completely sure how to proceed, though one idea might be to find > the most recent Python 2.[456] compatibility patch and then asking the > author whether this support is still relevant. I didn't know of that compatibility patch, though I'll try to track it down. (A pointer would be appreciated if you have one handy.) I decided that I had better educate myself about the old buffer protocol. I came across this page, which describes Python's old buffer protocol: https://docs.python.org/2/c-api/objbuffer.html The old buffer protocol includes the functions PyObject_CheckReadBuffer() and PyObject_AsReadBuffer() which are used in the non-IS_PY3K code in GDB. According to that page, the old buffer protocol was introduced in Python 1.6, but is deprecated in the 2.X series. It also indicates that support for the new buffer protocol, which is what I used in my patch, has been backported to Python 2.6. 2.6 was released in Oct of 2008. (I'm thinking that indicating that the old buffer protocol is deprecated in 2.X is a typo. I think they meant 3.X.) I'll try removing use of the old buffer protocol from GDB and then see if anything breaks with Python 2.7 (and maybe even 2.6 if I can figure out how to make that happen). If we get rid of the IS_PY3K ifdefs from GDB, we'll definitely be making this decision consciously. Kevin