This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Register sets


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]