From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rMeSKExS52M38i8AWB0awg (envelope-from ) for ; Sat, 11 Feb 2023 03:31:08 -0500 Received: by simark.ca (Postfix, from userid 112) id 991DD1E221; Sat, 11 Feb 2023 03:31:08 -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=k+EsHzUJ; 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=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 C97A31E0D3 for ; Sat, 11 Feb 2023 03:31:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 90414385842D for ; Sat, 11 Feb 2023 08:31:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 90414385842D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676104263; bh=bpSzM52B8dg7FBW24HJEPmpzhYhCq6zVC4h8tCZb+o8=; h=Date:To:Cc:In-Reply-To:Subject:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=k+EsHzUJn0yWnsABjS4KEvxZOcB/5MaTbslG08e0hR3Yv93Sz64FZ9ZuxrFsZX/dO N7Pc5JczvneQCWRQv/ZyjvjztY9mdi6mmDZlQ3qAwl6bFvhQhJbXy1WpINiryx/tt4 YFpdOe5aXo2jldGUI4MUu7IAkg6fbX6ZFTXFBezo= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id C64573858D32 for ; Sat, 11 Feb 2023 08:30:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C64573858D32 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQlH5-00059M-LH; Sat, 11 Feb 2023 03:30:23 -0500 Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQlGv-0004uL-NA; Sat, 11 Feb 2023 03:30:23 -0500 Date: Sat, 11 Feb 2023 10:29:43 +0200 Message-Id: <83mt5kk3k8.fsf@gnu.org> To: Tom Tromey Cc: gdb-patches@sourceware.org, mark@klomp.org In-Reply-To: <87a61lgcor.fsf@tromey.com> (message from Tom Tromey on Fri, 10 Feb 2023 19:26:12 -0700) Subject: Re: [RFC] Deprecate stabs References: <20230119174156.654402-1-tom@tromey.com> <83r0vqo15g.fsf@gnu.org> <83y1pxmi7b.fsf@gnu.org> <87a61lgcor.fsf@tromey.com> 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: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > From: Tom Tromey > Cc: Mark Wielaard , Eli Zaretskii , > tom@tromey.com > Date: Fri, 10 Feb 2023 19:26:12 -0700 > > >> stabs support was deprecated in GCC 12 [1] and has been removed in GCC > >> 13 [2], which is in pre-release state (stage 4) now. So the above plan > >> actually trails GCC by two releases. So I would actually recommend > >> adding a deprecation notice in GDB 13 and removal in GDB 14. > > Eli> I see no reason to rush with removal of features. Someone could still > Eli> be using them. And users don't necessarily upgrade to the latest > Eli> version of GCC as soon as it is released, they could go on using an > Eli> older version for some years. > > Eli> We should be friendlier to our users than MS and Google. > > I agree with all these principles, but they don't really apply to stabs. > > Stabs have been obsolete since before I began working on gdb. When I > worked at Red Hat, we'd occasionally stumble over some program using > them -- and this always turned out to be by mistake. That is, just user > ignorance, perhaps they read some web page from 1988 saying use -gstabs. You are probably thinking about using GDB on GNU/Linux. By contrast, on MS-Windows -gstabs was the only reasonable debug info type until GCC learned how to produce DWARF2 in PE-COFF images. I think GCC 3.x on Windows couldn't emit DWARF2 debug info. And don't get me started on go32 (a.k.a. DJGPP), where in some cases one still has to use -gcoff. > Similarly, when replying to bugs in bugzilla, more than once some crash > has turned out to be due to stabs being in use. I just tell those > people sorry, nobody works on stabs or even really understands the stabs > format or reader any more. And that is a perfectly valid response, IMO. But removing the support altogether means that it is unavailable even in those cases where it does not cause a crash. Which to me sounds too drastic. > If there is some person who really does use stabs, I don't think they'll > really be harmed by having to use GDB 13. 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. > Finally, deprecation serves the purpose of announcing our intent. So will the announcement of the feature being deprecated and unmaintained. It just lets the feature die of natural causes instead of euthanasia. > 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. That's what I think we should do: leave the code unmaintained, but not remove it in its entirety. Thanks.