Re: [RFC] Register sets

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Sep 04, 2003 at 11:04:18AM -0400, Andrew Cagney wrote:
> >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.

I don't know.

For core files, we have a BFD architecture to use to determine what the
name ".reg-xfp" means.  For remote targets we don't have an equivalent. 
It seems to me that the simplest way to handle this is to give them
distinct names.  I'd rather not require synchronizing this with BFD,
which isn't really designed to do this.

> 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.

Yes, 100% agree.

> >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 :-(

REGNUM -> {SETNAME, REGSET} would work, I suppose.  This would have to
be a per-consumer mapping?  We have defined G packets that are
different from defined core .reg sections.

> >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.

More or less, I suppose.  The supply function would not be explicitly
parametrized with regset-arch, unless that turns out to be necessary
and possible, but it would be implicitly parametrized and the mapping
function would consider regset-arch in selecting the function.  The
function would then supply registers in a way appropriate to the
regcache-arch.

> >>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.

No, Mark was passing in the core's architecture != the regcache's
architecture.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer