From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14242 invoked by alias); 4 Sep 2003 22:59:08 -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 14227 invoked from network); 4 Sep 2003 22:59:06 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 4 Sep 2003 22:59:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 353202B7F; Thu, 4 Sep 2003 18:59:06 -0400 (EDT) Message-ID: <3F57C3BA.50003@redhat.com> Date: Thu, 04 Sep 2003 22:59: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: Mark Kettenis Cc: drow@mvista.com, gdb@sources.redhat.com Subject: Re: [RFC] Register sets References: <200308232249.h7NMnvhh090154@elgar.kettenis.dyndns.org> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00069.txt.bz2 > 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. 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. > > As for the architecture, supply_regset needs this. It might, for > > instance, be an x86-64 method supplying registers to an i386 register cache. > > It needs the regcache's architecture, but I don't believe it needs any > other. The method will be defined for a particular regcache layout, > which incorporates all of the information it needs about the other > involved architecture. We could get the regcache's architecture from > the regcache, or pass it explicitly. > > See my reply to Daniels message earlier in this thread. Oh, and I do > think we should get the GDBARCH from the REGCACHE. We already can do > this for a frame so it makes sense to do it for a register cache too. > It's straightforward and I'll implement it this weekend. right (so my miss reading was correct :-) Andrew