From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6570 invoked by alias); 9 Nov 2003 20:38:38 -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 6563 invoked from network); 9 Nov 2003 20:38:36 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 9 Nov 2003 20:38:36 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D39462B8F; Sun, 9 Nov 2003 15:38:18 -0500 (EST) Message-ID: <3FAEA5BA.2050805@gnu.org> Date: Sun, 09 Nov 2003 20:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER References: <200311091207.hA9C7l5n064597@elgar.kettenis.dyndns.org> <3FAE4371.6010405@gnu.org> <200311091741.hA9Hf0cI015584@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00173.txt.bz2 > Date: Sun, 09 Nov 2003 08:38:57 -0500 > From: Andrew Cagney > > > I'm working on integrating some mostly SPARC-related patches from > > David S. Miller. There were also some general bits in his tree that > > I'm going to check in on mainline. Here's the first. > > You mean the stuff david posted here? > > Some of it has been posted, some hasn't. I explicitly asked David > about the copyright status, and he told me it was all written by > himself, and that is copyright assignment is still in place. > > > Committed as obvious (to mainline). > > It should be "m" or "M", and not "f". > You'll also note that I've started deleting still lurking macros so > these conversions are no longer so obvious :-) > > Hmm. So the "f" conversions are no longer considered obvious? The > problem with "m" and "M" is that they no longer define the macro that > we're replacing. That means things become a bit more complicated. Do > you want me to replace SKIP_SOLIB_RESOLVER with a truly multi-arched > function? Yep. More generally, I'd prefer to see people try to consolidate existing methods, or create a new "gdbarch has-a" relationship(1), rather than add yet another architecture method. The architecture vector contains so much redundancy that it is depressing. Any way, for your case, make the default something like: CORE_ADDR cannot_skip_solib_resolver (struct gdbarch *gdbarch, CORE_ADDR pc) { #ifdef SKIP_SOLIB_RESOLVER /* Ok the function's name is a lie. This is here to prop up old architectures and should be deleted. */ return SKIP_SOLIB_RESOLVER(...); #else return 0; #endif } Then the macro can be deprecated. Andrew (1) As in gdbarch has-a reggroup, gdbarch has-a unwinder, gdbarch has-a regset, ...