From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8656 invoked by alias); 7 Dec 2004 23:08:24 -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 8631 invoked from network); 7 Dec 2004 23:08:18 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 7 Dec 2004 23:08:18 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id 773E86BE3A; Tue, 7 Dec 2004 15:08:16 -0800 (PST) Date: Tue, 07 Dec 2004 23:27:00 -0000 From: Randolph Chung To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] first cut of solib-som.[ch] Message-ID: <20041207230816.GE6359@tausq.org> Reply-To: Randolph Chung References: <20041207052424.GU6359@tausq.org> <20041207102838.190db2d3.kevinb@redhat.com> <20041207211735.GD6359@tausq.org> <20041207150227.5e30b125.kevinb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207150227.5e30b125.kevinb@redhat.com> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-12/txt/msg00219.txt.bz2 > I'm comfortable with either approach. It makes a certain amount of > sense to initialize the solib related portions of the tdep struct from > within a solib-*.c file. OTOH, it also makes sense to not clutter the > solib-*.c file with knowledge of a particular architecture's tdep > struct. In this case, solib-som.c will probably not be used by any > other architectures, so it doesn't make much difference. I'll leave > it to you to choose the approach which you like better. well, for me it boils down to a dependency problem, which is still a bit tricky at the moment. what i would like to see is: 32-bit hpux targets will build only solib-som.*, and only support 32-bit debugging 64-bit hpux targets will build both solib-som.* and solib-pa64.*, and support both 32-bit and 64-bit debugging the problem in this scenario is that in the common hpux file (i.e. hppa-hpux-tdep.c), in order to support both configurations, we cannot refer to anything that is in solib-pa64.*. this is already a problem if i need to call e.g. pa64_solib_select (), and it becomes worse if we expose the solib methods to the tdep file. i'm thinking that the best way to do this is: - have the 32-bit hpux configs define PA_SOM_ONLY (as they do now) - unconditionally build both solib-som.c and solib-pa64.c into all hpux targets - in solib-pa64.c, make everything compile out if PA_SOM_ONLY is defined, except for a stub pa64_solib_select () is there a cleaner way? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/