From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 422dGqy462OGtzIAWB0awg (envelope-from ) for ; Tue, 14 Feb 2023 11:37:00 -0500 Received: by simark.ca (Postfix, from userid 112) id 5B8FD1E221; Tue, 14 Feb 2023 11:37:00 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=QfEW86fK; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E16191E0D3 for ; Tue, 14 Feb 2023 11:36:59 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0E6C33858412 for ; Tue, 14 Feb 2023 16:36:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0E6C33858412 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676392619; bh=2I2fgs3EW1V5yUuhglVxkiucCj3qmaubF2a+NK9c/NY=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=QfEW86fK4N0HFTqh3t7DqUbeRaPJ6zTDb2dOzpnfFDGK7kCvngc9D7gyZSAm88JeG d/RVDOaEYMpEs73pRot2yxDmfCnVFTLKnoR/1FLbW1G9IOkZTy8i/dXEBxzRobaKvq UOoBYE7gjMNokn9TDbKe4v5w2gMoqgg3xNtqCFyA= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 51CB4385840C for ; Tue, 14 Feb 2023 16:36:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51CB4385840C Received: from [172.16.0.146] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BB2881E0D3; Tue, 14 Feb 2023 11:36:25 -0500 (EST) Message-ID: <3dd3a681-9058-0fcc-b27a-a7e4848ec236@simark.ca> Date: Tue, 14 Feb 2023 11:36:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [RFC] Deprecate stabs To: Eli Zaretskii , Tom Tromey Cc: gdb-patches@sourceware.org, mark@klomp.org References: <20230119174156.654402-1-tom@tromey.com> <83r0vqo15g.fsf@gnu.org> <83y1pxmi7b.fsf@gnu.org> <87a61lgcor.fsf@tromey.com> <83mt5kk3k8.fsf@gnu.org> Content-Language: fr In-Reply-To: <83mt5kk3k8.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > This is based on the assumption that GDB 13 (or any other old version) > can be built on any future system without trouble. But that is false, > because systems are upgraded and make old versions fail to build, > since no one takes care of adapting old versions to new libraries and > changes in system calls. So the moment comes soon enough when using > an old version of GDB on a contemporary system is no longer an option. At this point, people who want stabs support can take care of keeping GDB 13 building on whatever system they are using. We're talking about something that has been obsolete for at least 15 years, not something that has been been obsoleted last year. > So will the announcement of the feature being deprecated and > unmaintained. It just lets the feature die of natural causes instead > of euthanasia. What does "die of nature causes" mean? It's not like the code will naturally disappear if we don't delete it. >> Maybe someone will step up to maintain this code, in which case we >> can keep it. In this scenario, I would be ok with treating it like >> the un-maintained *-nat code -- we'll try to keep it building but >> testing and fixing it is up to the maintainer. Agreed. > That's what I think we should do: leave the code unmaintained, but not > remove it in its entirety. It still gets in the way when doing changes to the generic symbol infrastructure. You have to think about how to adjust stabs, you can't just ignore it. Simon