[RFC] Register sets

[Andrew Cagney]

> On Thu, Sep 04, 2003 at 10:00:39AM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> >Hmm, yes and no.  That definition of regset is only useful for core
>> >files; I would like something more generally useful, for remote and
>> >native use.  I also don't really like passing the core gdbarch around,
>> >for the same reason.  How about this instead?
>> >
>> >struct regset
>> >{
>> >  void (*supply_regset)(struct regcache *, const void *, size_t, int);
>> >  void (*read_regset)(struct regcache *, void *, size_t, int);
>> >};
>> >
>> >const struct regset *
>> >core_section_to_regset (struct gdbarch *core_gdbarch,
>> >			const char *sec_name, size_t sec_size);
>> >
>> >which would then allow:
>> >
>> >const struct regset *
>> >remote_name_to_regset (const char *name);
> 
>> 
>> As far as I know, the required lookups are:
>> 	REGNUM -> REGSET
>> 	foreach REGSET
>> and not SETNAME -> REGSET.  This is so that a request for a single 
>> register, or all registers, can be directed to the correct regset.  I 
>> also think having remote and corefile adopt an identical naming schema 
>> should make life easier.
> 
> 
> I'd really rather not enforce that - remote can provide regsets that
> BFD doesn't know about, and the ".reg" names would look silly being
> defined as part of the remote protocol.  My instinct says that the
> flexibility is worthwhile so that the two implementation details don't
> become coupled.

It's best to delay adding generality until there is hard evidence 
supporting its need.

The core file's "reg" layout is pretty much wired down - it lets GDB 
adopt an existing standard.  Also, passing the BFD regset name down to 
the remote end makes for a very simple remote core file reader. 
Finally, if the remote end has a regset missing from the core file, then 
the core file spec needs to be extended to include it - cf 
GET_THREAD_INFO on i386, or the system registers from a core.

The original remote code had this right (intentional or not I don't 
know) - "G" transfered the general registers or the gregset. 
Unfortunatly, at some point in the mid '90's GDB lost the plot.  Instead 
of adding other packets to fetch other regset's the G packet started 
growing :-(  Getting regset's back into the protocol would be a good idea.

> I believe REGSET->SETNAME is necessary for the remote protocol approach
> I described.  Don't necessarily want to fetch all register sets, so we
> need to figure out the name of the one we do want.  You could implement
> the core side with REGSET->SETNAME and foreach REGSET, but I think it's
> more straightforward with SETNAME->REGSET.

Um, did you mean REGNUM -> {SETNAME, REGSET}?  It's the REGNUM that 
determines what happens next.  Otherwize I don't understand your point :-(

> Also, core_section_to_regset is more than just SETNAME->REGSET.  It
> considers the regset's size and core file's architecture, for reasons
> Mark described.

Ah!  So you're suggesting a table of regcache-arch X regset-arch?  That 
requirement isn't unique to core files.  /proc ptrace and other 
interfaces can also need such transformations.

>> As for the architecture, supply_regset needs this.  It might, for 
>> instance, be an x86-64 method supplying registers to an i386 register cache.
> 
> 
> It needs the regcache's architecture, but I don't believe it needs any
> other.  The method will be defined for a particular regcache layout,
> which incorporates all of the information it needs about the other
> involved architecture.  We could get the regcache's architecture from
> the regcache, or pass it explicitly.

That's the architecture mark was passing in.  The alternative is a 
larger table of regcache X regset maps.

>> I should note that I do know of a second way of handling cross 
>> architectures (x86-64 on i386 et.al.).  Add a table of cross 
>> architecture unwinders and then allow different frames to have different 
>> architectures vis:
>> 
>> 	x86-64 frame
>> 	<x86-64 X i386>
>> 	i386 frame
>> 	i386 frame
>> 	<ia64 X i386>
>> 	ia64 frame
>> 
>> but that's getting way ahead of many other changes.

Here the regcache and regset architecture would always match.  Cross 
architectures would be handled elsewhere.

Andrew