From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id CDD5D3844079 for ; Fri, 3 Jul 2020 15:15:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CDD5D3844079 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 544C61E111; Fri, 3 Jul 2020 11:15:03 -0400 (EDT) Subject: Re: GDB 10 branching - 2020-06-27 Update To: Joel Brobecker Cc: gdb-patches@sourceware.org, Tom Tromey References: <20200627154005.GA5618@adacore.com> <0b1b1404-d383-42de-1e7a-fca1a6df0a2d@simark.ca> <20200703150654.GJ5340@adacore.com> From: Simon Marchi Message-ID: <2239ac85-0c74-5be9-1489-a7a9830f0010@simark.ca> Date: Fri, 3 Jul 2020 11:15:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200703150654.GJ5340@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 15:15:04 -0000 On 2020-07-03 11:06 a.m., Joel Brobecker wrote: > I'll follow the group on that one. It's a risk vs reward situation: > How risky is it for us to put the patch in just before the branch, > versus how much do we expect to gain by having it now rather than > in 6 months? Given that this should only affect Guile support, > I suppose the risk we are taking is limited to that part. If the risk > is low and acceptable to everyone, then we can decide to have it > in GDB 10. I'll put it on the list for now... The patch is mostly adding new code guarded by #ifdefs based on the Guile version. So I think we can check and be reasonably confident that the code effectively used when building against guile 2.0 won't have changed much. All the new code will be compiled out when building against guile 2.0. There may be bugs in the support for guile 2.2/3.0 code, but that's a new feature, so it's better than no support at all. Simon