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

[Kevin Buettner <kevinb@redhat.com>]

On Mon, 6 Dec 2004 21:24:24 -0800
Randolph Chung <randolph@tausq.org> wrote:

> Here's a first cut at SOM solib support using the new solib
> infrastructure. I hope this is somewhat cleaner than the original
> somsolib.c.  The in_dynsym_resolve_code method is still really ugly; i
> hope to revisit that later. Can someone please review this and let me
> know if i'm on the right track?

Yes, you're definitely on the right track.  Thanks for doing this work!

> I've done some light testing with this
> using hppa2.0w-hp-hpux11.11. In some ways it works better than the
> existing code (e.g. info sharedlib will segfault the current gdb in
> cvs, but using this version works)
> 
> If this is ok, i'll check it in without linking it to anything. Will
> work on converting pa64solib next, and once that is ready we can enable
> that for hpux targets.

Sure, sounds good to me.

> 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...)

Just one comment about the way you structured things...

> +enum dld_list_offsets {
> +  DLD_LIST_OFFSET_NAME 			= 0,
> +  DLD_LIST_OFFSET_INFO 			= 4,
> +  DLD_LIST_OFFSET_TEXT_ADDR 		= 8,
> +  DLD_LIST_OFFSET_TEXT_LINK_ADDR 	= 12,
> +  DLD_LIST_OFFSET_TEXT_END 		= 16,
> +  DLD_LIST_OFFSET_DATA_START 		= 20,
> +  DLD_LIST_OFFSET_BSS_START 		= 24,
> +  DLD_LIST_OFFSET_DATA_END 		= 28,
> +  DLD_LIST_OFFSET_GOT_VALUE 		= 32,
> +  DLD_LIST_OFFSET_NEXT 			= 36,
> +  DLD_LIST_OFFSET_TSD_START_ADDR_PTR 	= 40,
> +  DLD_LIST_ENTRY_SIZE			= 44
> +};

I have no real quarrel with using offsets as you do above; in fact, 
I think such offsets have worked out quite well for solib-svr4.  However,
given that you have only one set of offsets to worry about, it might be
easier in some respects to use an actual struct where each member is
a char array.  (Daniel J showed me this trick...)  So, for the above,
you might instead do:

struct dld_list {
  unsigned char name[4];
  unsigned char info[4];
  unsigned char text_addr[4];
  ...
};

And then, for example, in som_current_sos(), instead of doing:

      char dbuf[DLD_LIST_ENTRY_SIZE];
      ...
      addr = extract_unsigned_integer (&dbuf[DLD_LIST_OFFSET_NAME], 4);

You, could instead do:

      struct dld_list dbuf;
      ...
      addr = extract_unsigned_integer (&dbuf.name, sizeof(dbuf.name));

Kevin