From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116756 invoked by alias); 13 Jun 2017 12:53:27 -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 116727 invoked by uid 89); 13 Jun 2017 12:53:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*M:4692, converse, our X-HELO: esa4.dell-outbound.iphmx.com Received: from Unknown (HELO esa4.dell-outbound.iphmx.com) (68.232.149.214) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Jun 2017 12:53:25 +0000 Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2017 07:53:22 -0500 From: Received: from ausxippc106.us.dell.com ([143.166.85.156]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2017 18:50:21 +0600 X-LoopCount0: from 10.175.218.62 To: CC: , Subject: Re: [PATCH] Fix python compatibility with old versions of GDB Date: Tue, 13 Jun 2017 12:53:00 -0000 Message-ID: <9572671A-5A73-4692-861A-4D9D8FDF9540@dell.com> References: <227db26304444bfb5ed8f699ab67e7fd@polymtl.ca> In-Reply-To: <227db26304444bfb5ed8f699ab67e7fd@polymtl.ca> Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2017-06/txt/msg00381.txt.bz2 > On Jun 13, 2017, at 7:23 AM, Simon Marchi wrote: >=20 > On 2017-06-12 06:31, Orgad Shaneh wrote: >> On Mon, Jun 12, 2017 at 12:09 AM, Simon Marchi = wrote: >>> Hi Orgad, >>> I still don't understand what problem this is trying to fix. It looks = like >>> you want to make older versions of GDB work with newer versions of the >>> Python scripts in the data directory. I am not sure this is what we wa= nt. >>> If you want multiple version of GDB in parallel on a system, they shoul= d all >>> be compiled with a different --prefix, and they will all get their own >>> data-directory. We should only expect a certain version of the data >>> directory to be compatible with the version of GDB it was shipped with.= Or >>> am I missing some use case where this is not true? >> Hi, >> Practically the data-directory is mostly backwards-compatible, except th= is >> small part which I found (there might be others which I didn't find). Wi= th this >> patch, I'm able to run GDB 7.8 with the latest data-directory. >> Is there a reason not to accept it? >=20 > I'd like to know what other maintainers think about this. We may have al= ready faced this situation before and taken a decision which I'm not aware = of. Otherwise, we need to take it now. Are we talking about GDB-supplied scripts, or user scripts? For scripts that come with GDB, the script comes with the rest of GDB so it= can be specific to a version. That makes for more work in creating or mod= ifying GDB, but it's our problem. User scripts should deliver backward compatibility: a script that conforms = to the documented API should continue to work in later releases. The conve= rse doesn't hold, of course: a script written to the latest API doesn't nec= essarily work with older versions, just as a program written to C11 doesn't= necessarily compile or run with C89. As for Python 2 vs. 3, GDB supports both and the Python-facing API is the s= ame (modulo the places where Python 3 itself is different, such as around s= trings vs. bytes or ints vs. long ints). A simple script may work with bot= h; a more complex script might not be unless the author goes through some e= ffort to make it so. But that's not particularly related to GDB, it's more= a question of how you write Python-version-independent scripts. paul