Re: [RFC] Register sets

Andrew Cagney
2003-09-09T04:21:23Z

> 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