Re: [RFC] Register sets

[Andrew Cagney <ac131313@redhat.com>]

>    >  * `gregset' for the general-purpose registers.
>    > 
>    >  * `fpregset' for the floating-point registers.
>    > 
>    >  * `xregset' for any "extra" registers.
> 
>    I don't think this is a good assumption.  There are two problems with
>    it:
> 
>      - It assumes that everything relating to a particular target uses the
>    same register set format.  In general (there are exceptions where
>    libthread_db will zero the regset instead of calling ps_*getregs) we
>    can pass regsets through libthread_db as opaque objects; we might wish
>    to include registers that are not available in a core dump.  Then we've
>    got two different "general" regsets.  There are some other examples.

FYI, the table will definitly need to be generalized.

The i386 GNU/Linux (glibc and the kernel collued on this one :-) 
PTRACE_GET_THREAD_AREA is really an additional register set and should 
be implemented as such.

(oh, must remember to expand "unsigned long int desc[3]" to 4 words).

> That's quite true.  It's probably a better idea to have the
> possibility of defining register sets for these particular purpose,
> falling back on a generic definition if those register sets aren't
> defined.  That keeps things simple for "sane" targets.

I did this for reggroups.  If the architecture does nothing a ""sane"" 
register grouping is defined.

Otherwize, the architecture can override everthing.

> Anyway, it's not a good idea to use the register set definition from
> the acrhitecture vector for ptrace(2) anyway.  On FreeBSD I can run
> Linux binaries.  But ptrace(2) still returns the registers in the
> FreeBSD fromat for them (unless GDB itself is a Linux binary).  So
> using the Linux register set definitions would make things fail,
> whereas using FreeBSD's register set format make it possible to debug
> a Linux binary on FreeBSD :-).  Similar things play a role when
> debugging 32-bit code on a 64-bit platform such as amd64, but probably
> also sparc64.

Yes.  Assume nothing.



>    > If REGNUM is -1, these function operate on all registers within the set.
> 
>    Can we define the REGNUM != -1 case a little more clearly?  Is the
>    regnum a hint, what registers must be valid in the regcache when
>    collecting, what registers must be valid in the regset when supplying,
>    et cetera.  Right now we're a bit inconsistent between targets.
> 
> It's pretty clear.  If REGNUM is not -1, only that particular register
> is transferred between the register cache and the buffer.  If REGNUM
> is -1, all registers (within the set) are transferred.  When
> collecting, this doesn't pay attention to the validity of the data.

FYI, given a request for REGNUM (>= 0) the code must supply at least 
that register (but is free to supply others).

The fun starts when trying to interpret target_fetch_registers(-1).  I 
guess it really does fetch all register sets.

There's a more general problem here (JeffJ pointed it out to me).  At 
present "gcore" obtains the registers being saved using regcache 
collect.  Unfortunatly, there's a missing target_fetch_registers(-1) 
call, and, as a consequence, the registers written out can be invalid 
:-(  There are several issues here: should "gcore" use regcache collect 
directly (bypassing the register fetch mechanism); if not, should this 
regset methods be parameterized with the function that should be used 
when collecting the registers (see regcache_cooked_read_ftype)?

>    > For each architecture we will have a structure that contains all
>    > information about the register sets:
>    > 
>    > struct regset_info
>    > {
>    >   size_t sizeof_gregset;
>    >   void (*supply_gregset)(struct regcache *, const void *, int);
>    >   void (*collect_gregset)(const struct regcache *, void *, int);
>    >   size_t sizeof_fpregset;
>    >   void (*supply_fpregset)(struct regcache *, const void *, int);
>    >   void (*collect_fpregset)(const struct regcache *, void *, int);
>    >   size_t sizeof_xregset;
>    >   void (*supply_xregset)(const struct regcache *, void *, int);
>    >   void (*collect_xregset)(const struct regcache *, void *, int);
>    > };

I think they should take a the size of the buffer as a parameter - trust 
me here - my i386 x86-64 code kept overflowing buffers :-(

>    > A pointer to this structure will be stored in the architecture vector,
>    > such that we can use this from various places in GDB.
>    > 
>    > Thoughts?
> 
>    I was thinking of something like this, very roughly:
> 
>    struct regset
>    {
>      size_t size;
>      mapping_of_registers_and_sizes_and_offsets mapping;
>    };

>    struct native_regsets
>    {
>      struct regset *gregset, *fpregset, *xregset;
>    };
> 
>    struct regset *
>    gdbarch_core_section_to_regset (int which, int sizeof);
> 
>    This would replace lots of identical copies of fetch_core_registers all
>    over GDB.
> 
> That's exactly what I'm aiming at :-).  The "mapping" needs to be a
> function though, since in some cases it might need to do some
> arithmetic on the buffer contents in order to convert them to the
> format used by GDB's register cache.

Yes.  Functions will work better.

--

What's the relationship between the regset and the regcache?  That is, 
are the supply/collect methods going to be expected to work with fairly 
arbitrary register caches or with just a single "unified" register cache?

This gets into a dangling question of how to best handle combinations of 
ABI, ISA and OS.  For instance, o32 run on IRIX 64 and where to best put 
indirection:

- on the supply side as I did for x86-64 i386
- on the cooked->raw regcache side as MIPS currently kind of does
- on the frame side (where a dummy frame does the mapping)

However, the dangling question shouldn't get in the way of these changes.

--

Just a heads up, I intend making things more thread/frame friendly this 
time round.  This means that, at some point, you might find that what 
was supply_register(regnum, buf) gets converted into 
cache_supply_register (cache, regnum, buf).  However, that's orthogonal, 
  just don't be suprized if it happens at some point.


>    How does that sound?  I'll implement it if folks like it.  Open to
>    any/all suggestions.
> 
> I have to think about this a bit more...

Yes.

Need to figure out how to relate these regsets back to ptrace/proc 
requests in some sort of generic way.  Doing the same for remote would 
hopefully then fall out.

enjoy,
Andrew