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

Kevin Buettner kevinb@redhat.com
Tue Dec 7 22:18:00 GMT 2004

On Tue, 7 Dec 2004 13:17:35 -0800
Randolph Chung <randolph@tausq.org> 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.


More information about the Gdb-patches mailing list