From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7361 invoked by alias); 10 Nov 2003 21:49:58 -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 7304 invoked from network); 10 Nov 2003 21:49:55 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 10 Nov 2003 21:49:55 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id hAALnm80000260; Mon, 10 Nov 2003 22:49:48 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id hAALnlNT000484; Mon, 10 Nov 2003 22:49:47 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id hAALnli4000481; Mon, 10 Nov 2003 22:49:47 +0100 (CET) Date: Mon, 10 Nov 2003 21:49:00 -0000 Message-Id: <200311102149.hAALnli4000481@elgar.kettenis.dyndns.org> From: Mark Kettenis To: cagney@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <3FAEA5BA.2050805@gnu.org> (message from Andrew Cagney on Sun, 09 Nov 2003 15:38:18 -0500) 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> <3FAEA5BA.2050805@gnu.org> X-SW-Source: 2003-11/txt/msg00196.txt.bz2 Date: Sun, 09 Nov 2003 15:38:18 -0500 From: Andrew Cagney > 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. gdbarch has-a shared library architecture. Yes, we defenitely need that. I have some thoughts on it. But I want to finish SPARC and the corefile stuff first... 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. I'll get rid of the SKIP_SOLIB_RESOLVER macro completely, but unfortunately I won't have time to do this before friday. Mark