From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23349 invoked by alias); 8 May 2005 14:40:56 -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 23310 invoked by uid 22791); 8 May 2005 14:40:53 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 08 May 2005 14:40:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DUmxA-0002Gj-3P; Sun, 08 May 2005 10:40:20 -0400 Date: Sun, 08 May 2005 14:48:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Unconditionally include shared library code Message-ID: <20050508144020.GA8650@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <200505021251.j42CpxIZ010109@elgar.sibelius.xs4all.nl> <200505081315.j48DF8AG030440@elgar.sibelius.xs4all.nl> <20050508135839.GA7384@nevyn.them.org> <200505081421.j48ELoGI020668@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505081421.j48ELoGI020668@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00191.txt.bz2 On Sun, May 08, 2005 at 04:21:50PM +0200, Mark Kettenis wrote: > Me neither. The usage is very inconsistent within GDB, using both > shlib and solib in interface dealing with shared libraries. I'd > certainly be in favor on us standardizing on one of the two (and I've > got a slight preference to use shlib). It would be great if we could > reach agreement on a consistent naming convention That would make for > an afwul lot of obvious patches. I have a slight preference to solib, since that's what the machinery currently uses. > But the problem I'm addressing here is solib.h. It contains both the > prototypes for the functions in solib.c and the #defines for the hooks > that make core GDB use those functions. Since the goal of my patch is > to get away from using those #defines, I can't simply #include solib.h > in the core GDB source files, unless I do a massive conversion of all > targets using solib.h. That, I think is rather dangerous. I'd rather > convert them one-by one, after I've verified that indeed they work > using the new mechanism. What bugs me about it is that it's not clear which one is going away. Would this alternative work for you? Create a new file, solib-macros.h, and move the macros from solib.h there. Have any targets which currently include solib.h via their TM_FILE include solib-macros.h instead, which is a nice mechanical update. -- Daniel Jacobowitz CodeSourcery, LLC