This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] first cut of solib-som.[ch]
- From: Randolph Chung <randolph at tausq dot org>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 7 Dec 2004 13:17:35 -0800
- Subject: Re: [rfc] first cut of solib-som.[ch]
- References: <20041207052424.GU6359@tausq.org> <20041207102838.190db2d3.kevinb@redhat.com>
- Reply-to: Randolph Chung <randolph at tausq dot org>
> > 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/