From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17319 invoked by alias); 4 Sep 2003 22:05: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 17304 invoked from network); 4 Sep 2003 22:05:20 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 4 Sep 2003 22:05:20 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p2/8.12.5) with ESMTP id h84M51dG008334; Fri, 5 Sep 2003 00:05:01 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6) with ESMTP id h84M51WQ034343; Fri, 5 Sep 2003 00:05:01 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p2/8.12.6/Submit) id h84M506L034340; Fri, 5 Sep 2003 00:05:01 +0200 (CEST) Date: Thu, 04 Sep 2003 22:05:00 -0000 Message-Id: <200309042205.h84M506L034340@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@mvista.com CC: ac131313@redhat.com, gdb@sources.redhat.com In-reply-to: <20030904140822.GA22838@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 4 Sep 2003 10:08:23 -0400) 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> X-SW-Source: 2003-09/txt/msg00066.txt.bz2 Date: Thu, 4 Sep 2003 10:08:23 -0400 From: Daniel Jacobowitz On Thu, Sep 04, 2003 at 10:00:39AM -0400, Andrew Cagney wrote: > > >Hmm, yes and no. That definition of regset is only useful for core > >files; I would like something more generally useful, for remote and > >native use. I also don't really like passing the core gdbarch around, > >for the same reason. How about this instead? > > > >struct regset > >{ > > void (*supply_regset)(struct regcache *, const void *, size_t, int); > > void (*read_regset)(struct regcache *, void *, size_t, int); > >}; > > > >const struct regset * > >core_section_to_regset (struct gdbarch *core_gdbarch, > > const char *sec_name, size_t sec_size); > > > >which would then allow: > > > >const struct regset * > >remote_name_to_regset (const char *name); > > As far as I know, the required lookups are: > REGNUM -> REGSET > foreach REGSET > and not SETNAME -> REGSET. This is so that a request for a single > register, or all registers, can be directed to the correct regset. I > also think having remote and corefile adopt an identical naming schema > should make life easier. 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. > 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. > I should note that I do know of a second way of handling cross > architectures (x86-64 on i386 et.al.). Add a table of cross > architecture unwinders and then allow different frames to have different > architectures vis: > > x86-64 frame > > i386 frame > i386 frame > > ia64 frame > > but that's getting way ahead of many other changes. A cross unwinder here would be a method that converts say an amd64 register cache into an i386 register cache (among other things)? Mark