From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23801 invoked by alias); 18 May 2012 12:23:35 -0000 Received: (qmail 23791 invoked by uid 22791); 18 May 2012 12:23:34 -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; Fri, 18 May 2012 12:23:17 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SVMDC-0003XB-0B from Maciej_Rozycki@mentor.com ; Fri, 18 May 2012 05:23:14 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 May 2012 05:23:13 -0700 Received: from [172.30.1.131] (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; Fri, 18 May 2012 13:23:10 +0100 Date: Fri, 18 May 2012 12:23:00 -0000 From: "Maciej W. Rozycki" To: Joel Brobecker CC: Tom Tromey , Mark Kettenis , , , Subject: Re: [SH] regs command In-Reply-To: <20120517203757.GG10253@adacore.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> 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/msg00676.txt.bz2 On Thu, 17 May 2012, Joel Brobecker wrote: > > I tend to agree with Mark that changing the init order in response to > > this problem is perhaps not wise. > > OK, I think that settles it. While I agree that this command deprecation case may not be important enough to make a decision on an internal API change weeks before a release, that does not mean the problem is not there. For example as recently as yesterday I came across this piece (in mips-linux-tdep.c): static struct target_so_ops mips_svr4_so_ops; [...] /* Initialize this lazily, to avoid an initialization order dependency on solib-svr4.c's _initialize routine. */ if (mips_svr4_so_ops.in_dynsym_resolve_code == NULL) { mips_svr4_so_ops = svr4_so_ops; mips_svr4_so_ops.in_dynsym_resolve_code = mips_linux_in_dynsym_resolve_code; } set_solib_ops (gdbarch, &mips_svr4_so_ops); that I find all but clean -- I can't even tell straight away, without studying all the code involved and perhaps experimenting, if this indeed is going to work correctly regardless of whether this is run before or after the other piece referred. And of course, this being an internal API that we can change arbitrarily at any time, including to reverse an earlier decision that turned out not to work as well as expected, I am not thoroughly convinced this moment is any worse than any other. Maciej