From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7895 invoked by alias); 7 Dec 2004 22:02:45 -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 7831 invoked from network); 7 Dec 2004 22:02:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Dec 2004 22:02: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 iB7M2Xvp001729 for ; Tue, 7 Dec 2004 17:02: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 iB7M2Xr04060; Tue, 7 Dec 2004 17:02: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 iB7M2XqY000654; Tue, 7 Dec 2004 17:02:33 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with SMTP id iB7M2RWi018144; Tue, 7 Dec 2004 15:02:27 -0700 Date: Tue, 07 Dec 2004 22:18: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: <20041207150227.5e30b125.kevinb@redhat.com> In-Reply-To: <20041207211735.GD6359@tausq.org> References: <20041207052424.GU6359@tausq.org> <20041207102838.190db2d3.kevinb@redhat.com> <20041207211735.GD6359@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/msg00217.txt.bz2 On Tue, 7 Dec 2004 13:17:35 -0800 Randolph Chung wrote: > > > One interesting bit for hpux is that for hppa64-hpux, to support both > > > 32-bit and 64-bit debugging at the same time, we will need multiarched > > > solib support as well. My plan is to call either som_solib_select () > > > [below] or pa64_solib_select () in the osabi sniffer to set the correct > > > current_target_so_ops. Is that how it is supposed to work? > > > > Yes, this seems reasonable. (At least for the short term; I think Mark > > is working on something for the long term...) > > ok, one more twist... > > there are some hpux specific solib methods that are required. i'm > assuming that these should go into the gdbarch_tdep vector, i.e. i'm > adding these to the hppa tdep structure: > > /* These are solib-dependent methods. They are really HPUX only, but > we don't have a HPUX-specific tdep vector at the moment. */ > CORE_ADDR (*solib_thread_start_addr) (struct so_list *so); > CORE_ADDR (*solib_get_got_by_pc) (CORE_ADDR addr); > CORE_ADDR (*solib_get_solib_by_pc) (CORE_ADDR addr); So far, so good. > and these pointers are initizlied by som_solib_select () or > pa64_solib_select () to the corresponding implementation. this will get > rid of the PA_SOM_ONLY hack i added some time back to get > hppa64-hp-hpux11.11 to build... The other way to do it is to initialize the HPUX specific tdep struct from the same function which calls som_solib_select() or pa64_solib_select(). That way, you might not have to #include "hppa-tdep.h" in solib-som.c. > is this ok? 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. Kevin