From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5267 invoked by alias); 26 Aug 2003 15:49:09 -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 5255 invoked from network); 26 Aug 2003 15:49:06 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 26 Aug 2003 15:49:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 572572B7F; Tue, 26 Aug 2003 11:49:07 -0400 (EDT) Message-ID: <3F4B8173.1000302@redhat.com> Date: Tue, 26 Aug 2003 15:49: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 , drow@mvista.com Cc: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00294.txt.bz2 > > * `gregset' for the general-purpose registers. > > > > * `fpregset' for the floating-point registers. > > > > * `xregset' for any "extra" registers. > > I don't think this is a good assumption. There are two problems with > it: > > - It assumes that everything relating to a particular target uses the > same register set format. In general (there are exceptions where > libthread_db will zero the regset instead of calling ps_*getregs) we > can pass regsets through libthread_db as opaque objects; we might wish > to include registers that are not available in a core dump. Then we've > got two different "general" regsets. There are some other examples. FYI, the table will definitly need to be generalized. The i386 GNU/Linux (glibc and the kernel collued on this one :-) PTRACE_GET_THREAD_AREA is really an additional register set and should be implemented as such. (oh, must remember to expand "unsigned long int desc[3]" to 4 words). > That's quite true. It's probably a better idea to have the > possibility of defining register sets for these particular purpose, > falling back on a generic definition if those register sets aren't > defined. That keeps things simple for "sane" targets. I did this for reggroups. If the architecture does nothing a ""sane"" register grouping is defined. Otherwize, the architecture can override everthing. > Anyway, it's not a good idea to use the register set definition from > the acrhitecture vector for ptrace(2) anyway. On FreeBSD I can run > Linux binaries. But ptrace(2) still returns the registers in the > FreeBSD fromat for them (unless GDB itself is a Linux binary). So > using the Linux register set definitions would make things fail, > whereas using FreeBSD's register set format make it possible to debug > a Linux binary on FreeBSD :-). Similar things play a role when > debugging 32-bit code on a 64-bit platform such as amd64, but probably > also sparc64. Yes. Assume nothing. > > If REGNUM is -1, these function operate on all registers within the set. > > Can we define the REGNUM != -1 case a little more clearly? Is the > regnum a hint, what registers must be valid in the regcache when > collecting, what registers must be valid in the regset when supplying, > et cetera. Right now we're a bit inconsistent between targets. > > It's pretty clear. If REGNUM is not -1, only that particular register > is transferred between the register cache and the buffer. If REGNUM > is -1, all registers (within the set) are transferred. When > collecting, this doesn't pay attention to the validity of the data. FYI, given a request for REGNUM (>= 0) the code must supply at least that register (but is free to supply others). The fun starts when trying to interpret target_fetch_registers(-1). I guess it really does fetch all register sets. There's a more general problem here (JeffJ pointed it out to me). At present "gcore" obtains the registers being saved using regcache collect. Unfortunatly, there's a missing target_fetch_registers(-1) call, and, as a consequence, the registers written out can be invalid :-( There are several issues here: should "gcore" use regcache collect directly (bypassing the register fetch mechanism); if not, should this regset methods be parameterized with the function that should be used when collecting the registers (see regcache_cooked_read_ftype)? > > For each architecture we will have a structure that contains all > > information about the register sets: > > > > struct regset_info > > { > > size_t sizeof_gregset; > > void (*supply_gregset)(struct regcache *, const void *, int); > > void (*collect_gregset)(const struct regcache *, void *, int); > > size_t sizeof_fpregset; > > void (*supply_fpregset)(struct regcache *, const void *, int); > > void (*collect_fpregset)(const struct regcache *, void *, int); > > size_t sizeof_xregset; > > void (*supply_xregset)(const struct regcache *, void *, int); > > void (*collect_xregset)(const struct regcache *, void *, int); > > }; I think they should take a the size of the buffer as a parameter - trust me here - my i386 x86-64 code kept overflowing buffers :-( > > A pointer to this structure will be stored in the architecture vector, > > such that we can use this from various places in GDB. > > > > Thoughts? > > I was thinking of something like this, very roughly: > > struct regset > { > size_t size; > mapping_of_registers_and_sizes_and_offsets mapping; > }; > struct native_regsets > { > struct regset *gregset, *fpregset, *xregset; > }; > > struct regset * > gdbarch_core_section_to_regset (int which, int sizeof); > > This would replace lots of identical copies of fetch_core_registers all > over GDB. > > That's exactly what I'm aiming at :-). The "mapping" needs to be a > function though, since in some cases it might need to do some > arithmetic on the buffer contents in order to convert them to the > format used by GDB's register cache. Yes. Functions will work better. -- What's the relationship between the regset and the regcache? That is, are the supply/collect methods going to be expected to work with fairly arbitrary register caches or with just a single "unified" register cache? This gets into a dangling question of how to best handle combinations of ABI, ISA and OS. For instance, o32 run on IRIX 64 and where to best put indirection: - on the supply side as I did for x86-64 i386 - on the cooked->raw regcache side as MIPS currently kind of does - on the frame side (where a dummy frame does the mapping) However, the dangling question shouldn't get in the way of these changes. -- Just a heads up, I intend making things more thread/frame friendly this time round. This means that, at some point, you might find that what was supply_register(regnum, buf) gets converted into cache_supply_register (cache, regnum, buf). However, that's orthogonal, just don't be suprized if it happens at some point. > How does that sound? I'll implement it if folks like it. Open to > any/all suggestions. > > I have to think about this a bit more... Yes. Need to figure out how to relate these regsets back to ptrace/proc requests in some sort of generic way. Doing the same for remote would hopefully then fall out. enjoy, Andrew