From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7535 invoked by alias); 21 Jan 2002 20:46:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7489 invoked from network); 21 Jan 2002 20:46:53 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 21 Jan 2002 20:46:53 -0000 Received: from cse.cygnus.com (cse.sfbay.redhat.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id MAA01125; Mon, 21 Jan 2002 12:46:44 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g0LKjSA02094; Mon, 21 Jan 2002 13:45:28 -0700 Date: Mon, 21 Jan 2002 12:46:00 -0000 From: Kevin Buettner Message-Id: <1020121204528.ZM2093@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [PATCH RFA] Zap EXTRA_FRAME_INFO for ARM target" (Jan 20, 6:15pm) References: <1011215082551.ZM11544@ocotillo.lan> <3C4B4F9B.4090607@cygnus.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Andrew Cagney , Kevin Buettner , Richard Earnshaw , Fernando Nasser , Scott Bambrough Subject: Re: [PATCH RFA] Zap EXTRA_FRAME_INFO for ARM target Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00663.txt.bz2 On Jan 20, 6:15pm, Andrew Cagney wrote: > > The patch below represents a small step on the way to multiarching the > > ARM target. It eliminates the use of the deprecated EXTRA_FRAME_INFO > > macro for describing a frame. Instead, it now uses the ``extra_info'' > > and ``saved_regs'' members in the frame_info struct. > > Jason Thorpe (I assume unintentionally) set a precident by treating as > obvious the patch transforming EXTRA_FRAME_INFO as part of multi-arching > the alpha. > > Thinking about it Jason was correct in taking this aproach (I suspect > I've done this with other targets). A patch making the single > independant change of eliminating EXTRA_FRAME_INFO is mechanical, and as > such, can be treated as obvious. I think it depends upon the target. For ARM, nearly all of the changes were mechanical, but the ARM target has some pecularities which required some care. I think it would have been better for a responsive maintainer to have looked over these changes and approved them. I do agree, however, that Jason was correct in his approach for the alpha since the alpha target doesn't have any listed maintainers. > Clearly it is assumed that the person > committing the change is performing before/after testing to ensure no > regressions occure. A person looking to commit such a change is also, > obviously, strongly advised, to not try and make the change somehow > dependant on other changes, doing that will just bog down the process. Ah. Perhaps you're referring to the fact that my patch had some dependencies on other patches (which are now approved). I had considered removing these dependencies before submitting my patch, but that would've meant more work for me when it wasn't at all clear that there would be any benefit. > If GDB doesn't take this approach it is very quickly going to find that > the multi-arch task gets bogged down waiting on approval of trivial changes. I don't entirely agree with this. If the target in question has no maintainers, then I am in complete agreement. If the target in question has active maintainers, then I think the maintainers should have a chance to comment on the proposed changes before they go in. If Fernando and Scott no longer have the time or motivation to be active maintainers, then they should step aside so that development of the ARM target can proceed more rapidly. Kevin