From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9408 invoked by alias); 4 Sep 2003 15:04:18 -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 9401 invoked from network); 4 Sep 2003 15:04:18 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 4 Sep 2003 15:04:18 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 2F0A62B7F; Thu, 4 Sep 2003 11:04:18 -0400 (EDT) Message-ID: <3F575472.2030405@redhat.com> Date: Thu, 04 Sep 2003 15:04: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: <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00059.txt.bz2 > 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. It's best to delay adding generality until there is hard evidence supporting its need. The core file's "reg" layout is pretty much wired down - it lets GDB adopt an existing standard. Also, passing the BFD regset name down to the remote end makes for a very simple remote core file reader. Finally, if the remote end has a regset missing from the core file, then the core file spec needs to be extended to include it - cf GET_THREAD_INFO on i386, or the system registers from a core. The original remote code had this right (intentional or not I don't know) - "G" transfered the general registers or the gregset. Unfortunatly, at some point in the mid '90's GDB lost the plot. Instead of adding other packets to fetch other regset's the G packet started growing :-( Getting regset's back into the protocol would be a good idea. > I believe REGSET->SETNAME is necessary for the remote protocol approach > I described. Don't necessarily want to fetch all register sets, so we > need to figure out the name of the one we do want. You could implement > the core side with REGSET->SETNAME and foreach REGSET, but I think it's > more straightforward with SETNAME->REGSET. Um, did you mean REGNUM -> {SETNAME, REGSET}? It's the REGNUM that determines what happens next. Otherwize I don't understand your point :-( > Also, core_section_to_regset is more than just SETNAME->REGSET. It > considers the regset's size and core file's architecture, for reasons > Mark described. Ah! So you're suggesting a table of regcache-arch X regset-arch? That requirement isn't unique to core files. /proc ptrace and other interfaces can also need such transformations. >> 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. That's the architecture mark was passing in. The alternative is a larger table of regcache X regset maps. >> 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. Here the regcache and regset architecture would always match. Cross architectures would be handled elsewhere. Andrew