From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22673 invoked by alias); 18 May 2012 13:47:00 -0000 Received: (qmail 22665 invoked by uid 22791); 18 May 2012 13:46:58 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 May 2012 13:46:39 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IDkNJa025311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 09:46:23 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q4IDkLSv002751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 09:46:21 -0400 From: Tom Tromey To: "Maciej W. Rozycki" Cc: Joel Brobecker , Mark Kettenis , , , Subject: Re: [SH] regs command References: <87r4ukox0y.fsf@fleche.redhat.com> <20120516190539.GZ10253@adacore.com> <201205171109.q4HB9Ljc005742@glazunov.sibelius.xs4all.nl> <20120517123827.GB10253@adacore.com> <201205171522.q4HFMWGM026439@glazunov.sibelius.xs4all.nl> <20120517154502.GE10253@adacore.com> <87zk96k2my.fsf@fleche.redhat.com> <20120517203757.GG10253@adacore.com> Date: Fri, 18 May 2012 13:47:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Fri, 18 May 2012 13:22:59 +0100") Message-ID: <871umhk3f6.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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 X-SW-Source: 2012-05/txt/msg00684.txt.bz2 >>>>> "Maciej" == Maciej W Rozycki writes: Maciej> While I agree that this command deprecation case may not be important Maciej> enough to make a decision on an internal API change weeks before a Maciej> release, that does not mean the problem is not there. Yeah, I agree, there is a problem -- it is encountered infrequently enough that we can usually pretend it isn't there. There's also some places that were designed to avoid dependency problems, like the way command list roots are statically allocated. Basing the dependencies on file names doesn't seem robust. It works in this case; but I don't think there is a reason to believe it will always be a workable approach. I think one way to fix it would be to have the code express the dependencies. This might be tricky to maintain, though I suppose with enough assertions it could be robust. Tom