From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3162 invoked by alias); 13 Jun 2014 16:50:42 -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 3107 invoked by uid 89); 13 Jun 2014 16:50:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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; Fri, 13 Jun 2014 16:50:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5DGobv6019531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Jun 2014 12:50:37 -0400 Received: from barimba (ovpn-113-103.phx2.redhat.com [10.3.113.103]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5DGoZbi026033 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Jun 2014 12:50:36 -0400 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/7] more constification References: <1402512797-6082-1-git-send-email-tromey@redhat.com> <20140612084534.GC4730@adacore.com> Date: Fri, 13 Jun 2014 16:50:00 -0000 In-Reply-To: <20140612084534.GC4730@adacore.com> (Joel Brobecker's message of "Thu, 12 Jun 2014 10:45:34 +0200") Message-ID: <87a99gpxd0.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-06/txt/msg00533.txt.bz2 Tom> Patch #6 casts away const in a couple spots. There's a justification Tom> in the patch; but I also wanted to add that the casts only affect Tom> mdebugread.c, which can't really be said to be actively maintained in Tom> any case. Joel> I am wondering whether we should consider the option of deprecating Joel> those targets that use this code. This affects alpha-tru64 and Joel> maybe mips-linux (although - is that option still supported by Joel> GCC? And even if it was, who would want to use that object format Joel> instead of ELF???). It's also said to be used by some versions Joel> of IRIX, but I am not sure that GDB works on those - the ones Joel> we've been supporting until a few years ago were using ELF. There was this thread: https://www.sourceware.org/ml/gdb/2012-12/msg00052.html I somewhat recall looking into removing some of this code (I don't remember if it was mdebugread or something else) and finding to my dismay that it was intertwined with other somewhat more living code in a way that made it hard to untangle. I thought I sent a note about this, but I can't find it now. I'm generally in favor of removing things. gdb has too much moribund code. However it's not always easy to tell what is really dying, and one is less likely to get complaints about a patch than a removal. Perhaps at some point we can say it is either definitively dead or definitively broken (like the solib-sunos stuff last year) and then remove it. Tom