Re: [PATCH 7/8] ia64-hpux: unwinding bsp value from system call

[Joel Brobecker <brobecker at adacore dot com>]

> What is the underlying object you're getting those values from?
> I understood it to be whatever object TT_LWP_RUREGS accesses?
> You seem to call it save_state_t?  Why not TARGET_OBJECT_HPUX_RUREGS
> or TARGET_OBJECT_HPUX_SAVE_STATE, or something along those lines?
> Then, the offset, and length passed to target_xfer would the
> the offset and length you're currently passing to
> ia64_hpux_read_register_from_save_state_t.  This would allow
> (if useful) exporting this object similarly to the $_siginfo and
> $_tlb objects.

I cannot determine the offset from the tdep code.  The offset is
is a obtained by including one of the system hearders.

To widen a bit the discussion, I should mention that there is also
another object that I am trying to transfer in this patch set:
During an inferior function call, I need to set the global pointer,
and I can only get that global pointer from the shared-library
code (we extract a structure from memory which is also defined by
system headers). In both cases, I was (ab)-using TARGET_OBJECT_OSDATA.

My initial thoughts on the kind of object to be used were that we could
have one generic object which the targets were free to ues as they see
fit. Right now, we have TARGET_OBJECT_AVR, TARGET_OBJECT_SPU, etc.
It seems unnecessary to have one for each CPU since we can use
namespace conventions to make sure there are no collision.  I'm not
even sure that collisions are really a problem either, in fact.

Depending on which approach we use, I am proposing the following
target objects:

   (a) * TARGET_OBJECT_HPUX_STOP_REASON
         Returns a 1-byte object.
         0 == syscall context, non-zero == interruption context
       * TARGET_OBJECT_HPUX_SOLIB_GOT
         ANNEX contains an image of the PC for which we need the GOT
         Returns a CORE_ADDR that is either 0 if no shared library
         contains that PC, or else the associated SO's GOT.

   (b) One object for both datas:
       TARGET_OBJECT_HPUX, or TARGET_OBJECT_HPUX_DATA, or
       TARGET_OBJECT_TARGET_DATA, or TARGET_OBJECT_TDEP_DATA.

       In that case, the annex is used to determine which specific
       data the tdep code is looking for. I tend to like either
       TARGET_OBJECT_HPUX, or TARGET_OBJECT_TDEP_DATA, with a preference
       for the TARGET_OBJECT_TDEP_DATA.

-- 
Joel