Re: [RFC] Register sets

[Andrew Cagney <ac131313@redhat.com>]

> On Thu, Sep 04, 2003 at 06:59:06PM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> >   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.
> 
>> 
>> ... but here there is no suggestion that BFD should transform the 
>> corefile data when it is turned into register data, in fact the oposite 
>> is true.  The intent is for just GDB to know how to pack/unpack these 
>> regsets and then have BFD, proc, ptrace and the remote target all xfer 
>> uninterpreted bytes.  The natural format for those uninterpreted bytes 
>> is what ever is specified by the system being debugged.
> 
> 
> Eh?
> 
> The remote protocol is fixed.  The core file format is fixed.  The
> /proc output format is fixed.  They aren't all the same, so I don't
> see what this unity would accomplish - they have to be translated
> around anyway.

I wrote:

> ... but here there is no suggestion that BFD should transform the 
>> corefile data when it is turned into register data, in fact the oposite 
>> is true.  The intent is for just GDB to know how to pack/unpack these 
>> regsets and then have BFD, proc, ptrace and the remote target all xfer 
>> uninterpreted bytes.  The natural format for those uninterpreted bytes 
>> is what ever is specified by the system being debugged.

The translation would only need to be done once.  As they say, keep it 
simple.

>> This would let gdbserver thin down to the point where it only needed to 
>> know how to xfer those raw bytes - no need to repack them into a 
>> standard G packet.
>> 
>> Of course a heavy weight gdbserver could also use this regset code to 
>> repack bits into G and other packets before shipping them back to GDB.
> 
> 
> The lighter-weight version isn't of much interest now - a number of
> other issues have convinced me that lightening the stub further isn't
> the way to go.

The remote protocol has had a long standing conflict between two 
different register abstractions:

- the G model - things are just a large raw buffer
- the P model - registers can be individually identified

Truth is, both can and should be accomodated:

- fat stubs that can chat to gdb in terms of specific register numbers
- thin stubs that can just transfer the raw buffer (or part there of)

Trying to select one over the other has been a mistake - they are both 
correct and equally valid.

Andrew