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.
I'm with Daniel here. For most OS'es the corefile format isn't under
our control, and some of these formats simply don't make too much
sense. We shouldn't be forced to use those in the remote protocol.
And I don't think BFD should do a transformation on the corefile data
when it turns the register data into a section.
> 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.
See my reply to Daniels message earlier in this thread. Oh, and I do
think we should get the GDBARCH from the REGCACHE. We already can do
this for a frame so it makes sense to do it for a register cache too.
It's straightforward and I'll implement it this weekend.