Re: [RFC] Register sets

Andrew Cagney
2003-09-04T15:04:18Z

> 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