From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14931 invoked by alias); 9 May 2005 16:20:54 -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 14754 invoked from network); 9 May 2005 16:20:38 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 May 2005 16:20:38 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DVAzj-0005iR-BQ; Mon, 09 May 2005 12:20:35 -0400 Date: Mon, 09 May 2005 16:20:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sourceware.org Subject: Re: RFC: Available registers as a target property Message-ID: <20050509162035.GB20242@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sourceware.org References: <20050506162029.GA30792@nevyn.them.org> <200505071603.j47G3tuc030771@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505071603.j47G3tuc030771@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00111.txt.bz2 On Sat, May 07, 2005 at 06:03:55PM +0200, Mark Kettenis wrote: > Hi Daniel, > > Your proposal sounds reasonable to me. Do I understand correctly that > the "set" keyword is supposed to be used to specify the contents of > the `g' packet, or is there a somewhat broader use for them? I was thinking of a broader use. The only two "messages" I have worked with so far are not g-packet related; they are more like shorthand for groups of "reg" keywords. If the target supplied "iwmmxt:36" then the remote protocol would use p-packets based at register 0x36 to fetch the iwmmxt registers. This does raise an interesting question. Should a target specify _all_ of its available registers this way, including a predefined "set:standard:0"? Or should the standard registers be implicit, unless a set is specified which would conflict with them? There's something to be said for requiring explicit reference to the standard register set. For instance, for MIPS it isn't clear whether the 32-bit or 64-bit packet is "standard". On the other hand, it's no worse than the current situation if the target does not say. Anyway, just a thought. I think that the implicit reference is OK. But for some targets, like MIPS, supplying an explicit reference will probably be to the target's benefit, so it would provide "set:gprs32:0" or "set:gprs64:0". > Anyway, here are some random thoughts about things we might need to > consider. It's a bit i386 centric, the issues mostly are not. > > * Is this going to allow us to make changes freely to the internal > layout of GDB's register cache? The proposal, not specifically. The implementation, yes. It turns out that after the last generation of cleanups this is quite simple to do. All it required was a gdbarch method for mapping from GDB regnums to remote protocol regnums; I preserved the assumption that the g packet was contiguous and 0-based in the remote protocol numbering scheme, which I think is a reasonable assumption. > * How will we treat registers that the user might reasonably expect to > be there, but aren't made available by the target? > > FreeBSD/i386 for example still has no way to get at the SSE registers, > but has no problem executing code that uses its registers. What do we > do when the user says "print $xmm0" when connected to a FreeBSD/i386 > target? Do we print: > > (gdb) p $xmm0 > $1 = void > > or are we going to try to print a more helpful message for > well-known-but-unavailable registers? Good question. Unless additional work is done, you'd get void. It sounds like we need to define the registers with an "error" type; but my limited experience with GCC's type system tells me that that can get messy very quickly. How about a list of unavailable register names, provided by the architecture, and something parallel to the existing user-regs.c code to generate the error message? > * What do we do with pseudo registers? > > The ia32 MMX registers are optional pseudo registers; they reinterpret > the floating-point registers in a particular way. As such they won't > be transmitted between the target and GDB. Yet it would be nice if we > had a mechanism for the target to indicate whether MMX is available > such that GDB knows if it should display the MMX registers or not. This could either be a set keyword, or a new keyword; how about "feature:mmx", defaulting to available if the new mechanism is not used? > * How does this interact with register groups? > > Do we need a mechanism to indicate the register group to which a > register belongs, or is the default register group behaviour good > enough? I hadn't thought about this. It's a very complicated question. One of the nice things about using the "set" notation for groups of registers is that it allows and requires GDB to have a priori knowledge of the use and meaning of those registers. So in that case, the target's existing reggroup method can handle them. But for unknown registers something else may be necessary. The proposed register specifier was: reg:::::... Perhaps an additional field, call it TAGS, which could include things like "integer", "vector", "readonly" (this is important! I forgot to consider that). I am not sure how save_reggroup/restore_reggroup should be represented; does readonly cover all the cases where GDB should not save/restore a register around function calls? Probably not. [Reading this it occurs to me that the syntax above does not leave room to define new common information in the future, because target data is at the end. I may need to rethink that structure.] -- Daniel Jacobowitz CodeSourcery, LLC