Re: [RFC] Register sets

Andrew Cagney
2003-08-26T15:49:09Z

> > * `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