From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10002 invoked by alias); 21 May 2012 23:36:47 -0000 Received: (qmail 9789 invoked by uid 22791); 21 May 2012 23:36:45 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 May 2012 23:36:29 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SWc9K-0007f1-Ma from Maciej_Rozycki@mentor.com ; Mon, 21 May 2012 16:36:26 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 May 2012 16:36:07 -0700 Received: from [172.30.0.105] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 22 May 2012 00:36:24 +0100 Date: Mon, 21 May 2012 23:36:00 -0000 From: "Maciej W. Rozycki" To: Tom Tromey CC: Joel Brobecker , Mark Kettenis , , , Subject: Re: [SH] regs command In-Reply-To: <871umhk3f6.fsf@fleche.redhat.com> Message-ID: 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> <871umhk3f6.fsf@fleche.redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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/msg00799.txt.bz2 On Fri, 18 May 2012, Tom Tromey wrote: > 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. Yeah, let's pretend it isn't there. ;) > 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. Yes, this is fragile to say at least, I agree. > 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. Hmm, I gave it some thinking and it looks to me like a functional programming problem to solve (e.g. AC_REQUIRE in autoconf-speak; I didn't really do any functional programming beyond that). This may not be possible to express in C in a very elegant way, but I can imagine retaining the current init.c arrangement/scriptery, but in addition to that letting initialisers call one another. Then in each initialiser we could have: void _initialize_foo (void) { static int initialized; if (initialized > 0) return; else if (initialized < 0) internal_error (__FILE__, __LINE__, _("initialization loop")); else initialized = -1; [...] initialized = 1; } We might be able to hide this stuff in some macros so as to avoid repeating it across all files (and risking mistakes). This could avoid the need to copy these annoying prototypes to shut up GCC for each initialiser as well (but then the scripts could simply make init.h instead). Maciej