From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27041 invoked by alias); 8 May 2005 15:33:12 -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 26768 invoked by uid 22791); 8 May 2005 15:33:04 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 08 May 2005 15:33:04 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j48EpQsa015774; Sun, 8 May 2005 16:51:26 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j48EpP4G031395; Sun, 8 May 2005 16:51:25 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j48EpPTO013691; Sun, 8 May 2005 16:51:25 +0200 (CEST) Date: Sun, 08 May 2005 17:32:00 -0000 Message-Id: <200505081451.j48EpPTO013691@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sources.redhat.com In-reply-to: <20050508144020.GA8650@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 8 May 2005 10:40:20 -0400) Subject: Re: [RFC] Unconditionally include shared library code References: <200505021251.j42CpxIZ010109@elgar.sibelius.xs4all.nl> <200505081315.j48DF8AG030440@elgar.sibelius.xs4all.nl> <20050508135839.GA7384@nevyn.them.org> <200505081421.j48ELoGI020668@elgar.sibelius.xs4all.nl> <20050508144020.GA8650@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00195.txt.bz2 Date: Sun, 8 May 2005 10:40:20 -0400 From: Daniel Jacobowitz > 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. Hmm, that'd work. We'll have to face the inconsistent interface issue eventually, but it's a seperate issue indeed. Any objection if I introduce a config/tm-solib.h and use that? Its purpose is a bit more clear, and the risk of abuse is smaller. The mechanical update is not without risk, but I'm willing to take it. Deal? Mark