From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25657 invoked by alias); 7 Dec 2004 23:27:44 -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 25610 invoked from network); 7 Dec 2004 23:27:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Dec 2004 23:27:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB7NRX7l025019 for ; Tue, 7 Dec 2004 18:27:38 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB7NRXr27128; Tue, 7 Dec 2004 18:27:33 -0500 Received: from localhost.localdomain (vpn50-35.rdu.redhat.com [172.16.50.35]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id iB7NRWqY012491; Tue, 7 Dec 2004 18:27:33 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB7NRRJV018337; Tue, 7 Dec 2004 16:27:27 -0700 Date: Wed, 08 Dec 2004 00:02:00 -0000 From: Kevin Buettner To: Randolph Chung Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] first cut of solib-som.[ch] Message-ID: <20041207162726.030bb7cc.kevinb@redhat.com> In-Reply-To: <20041207230816.GE6359@tausq.org> References: <20041207052424.GU6359@tausq.org> <20041207102838.190db2d3.kevinb@redhat.com> <20041207211735.GD6359@tausq.org> <20041207150227.5e30b125.kevinb@redhat.com> <20041207230816.GE6359@tausq.org> Organization: Red Hat Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00220.txt.bz2 On Tue, 7 Dec 2004 15:08:16 -0800 Randolph Chung wrote: > > 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. Thanks for explaining this. Given this background, I think that your original approach of initializing a portion of the tdep struct from within solib-*.c is preferable. > 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? I can't think of one at the moment. So... go ahead with this approach. Kevin