This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Register sets
> * `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