From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23212 invoked by alias); 9 Sep 2003 04:21:23 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23204 invoked from network); 9 Sep 2003 04:21:22 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 9 Sep 2003 04:21:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DE1772B7F; Tue, 9 Sep 2003 00:21:18 -0400 (EDT) Message-ID: <3F5D553E.90607@redhat.com> Date: Tue, 09 Sep 2003 04:21:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: [RFC] Register sets References: <20030824164347.GA17520@nevyn.them.org> <200308252234.h7PMYqFu001245@elgar.kettenis.dyndns.org> <3F4B8173.1000302@redhat.com> <20030826165547.GA22836@nevyn.them.org> <86he3xrkjb.fsf@elgar.kettenis.dyndns.org> <20030904125514.GA2577@nevyn.them.org> <3F574587.70401@redhat.com> <20030904140822.GA22838@nevyn.them.org> <200309042205.h84M506L034340@elgar.kettenis.dyndns.org> <3F57C3BA.50003@redhat.com> <20030905231517.GA17046@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00109.txt.bz2 > 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