From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8163 invoked by alias); 7 Dec 2004 21:17:43 -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 8118 invoked from network); 7 Dec 2004 21:17:37 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 7 Dec 2004 21:17:37 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id AAF256BE38; Tue, 7 Dec 2004 13:17:35 -0800 (PST) Date: Tue, 07 Dec 2004 21:41: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: <20041207211735.GD6359@tausq.org> Reply-To: Randolph Chung References: <20041207052424.GU6359@tausq.org> <20041207102838.190db2d3.kevinb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041207102838.190db2d3.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/msg00214.txt.bz2 > > 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); 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... is this ok? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/