Re: [rfc] first cut of solib-som.[ch]

[Randolph Chung <randolph@tausq.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/