From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9439 invoked by alias); 5 Sep 2003 23:15:34 -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 9431 invoked from network); 5 Sep 2003 23:15:32 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Sep 2003 23:15:32 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19vPnS-0005SY-8j; Fri, 05 Sep 2003 19:15:18 -0400 Date: Fri, 05 Sep 2003 23:15:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: [RFC] Register sets Message-ID: <20030905231517.GA17046@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F57C3BA.50003@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00080.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. > 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. Things like kernel stubs have to convert anyway, since it's a whole different format. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer