From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13387 invoked by alias); 20 Jul 2002 18:39: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 4915 invoked from network); 20 Jul 2002 16:52:35 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 20 Jul 2002 16:52:35 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1AEC93E53; Sat, 20 Jul 2002 12:52:30 -0400 (EDT) Message-ID: <3D39954D.1020306@ges.redhat.com> Date: Sat, 20 Jul 2002 11:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020708 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: WIP: Register doco References: <3D38AF69.7020902@ges.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00206.txt.bz2 > I'm not saying the questions below couldn't be worked out by examining > the whole document carefully. But ideally, a document makes sense in > the first read-through. So, you're saying that this document doesn't make sense on a first reading? I'm not suprized! :-) >> @table @emph >> @item cooked >> @itemize @bullet >> @item >> manipulated by core @value{GDBN} >> @item >> correspond to user level, or abi registers > > > Don't you mean "ISA" here, not "ABI"? If I disassemble some code and > see an instruction that refers to r12, then I should be able to see > that register's value by saying "print $r12". The ABI in use has > nothing to do with it. No, ABI. For instance mipsIII and o32. The o32 ABI thinks registers have 32 bits yet the real register has 64 bits. This gives two views of the same register. When o32 debug info indicates a value in two adjacent registers, it is refering to 32 bit and not 64 bit registers. (Should user visible registers be displayed according to the underlying ISA or ABI is an item for debate. It has never been specified and I suspect in part because GDB, prior to gdbarch_register_read/write, couldn't handle both.) >> @end itemize >> @item raw >> @itemize @bullet >> @item >> manipulated by target backends >> @item >> correspond to physical registers > > > I think you're introducing a new term here, "physical", which doesn't > do anything for you. When I see "physical", I think of actual > flip-flops. But that's clearly not what you're talking about: GDB has > no idea how many ports these registers have, whether they get renamed > for speculative execution, etc. That was the intent. The objective is to focus the reader on the target architecture's hardware and identify the registers that correspond to real hardware. Often in GDB, people haven't focused on the hardware and its registers and instead stored cooked registers in the raw register cache. See older SH and bank registers or d10v and its two stack pointers. However, often, what GDB gets access to is actually the ``spill registers'' - the hardware registers saved to memory. I guess I should refine this. (Mind you, with a jtag target, it really is NAND and NOR gates :-) > In effect, all that phrase does is define "raw" in terms of another > undefined term, "physical". > > By "raw", do you really mean the registers as presented by the > underlying protocol GDB uses to examine the inferior (be it remote, > /proc, or ptrace)? I dunno. I'll likely change it to ``hardware'', I think I've been using that term more consistently elsewhere. >> @item >> For a 64 bit architecture that is running in 32 bit mode, the register >> cache and raw register space would contain the 64 bit hardware >> registers. The raw register space would not include cut down 32 bit >> registers. > > > By "32 bit mode", do you mean that there's an actual bit on the > processor that makes shift, divide, etc. instructions behave as if > there were only 32 bits? Or do you mean an ABI that simply only uses > the lower 32 bits of the registers? Who knows --- target architecture dependant detail. Some targets have a true 32 bit mode, some just run 32 bit ABI's on a 64 bit architectures. The MIPS floating point registers and their various modes shows how tangled the web can get. >> @item >> For an architecture that has memory mapped registers, those registers >> are not be part of the register cache or raw register space (there is no >> corresponding hardware register). > > > I think it would be nice to use the IA-64's arrangement as an example > here. I assume the raw registers would include the unrotated register > file, and the registers that determine how they're rotated at the > current point. Whereas the cooked registers would be numbered the way > they appear in the machine instructions. As a description of memory registers or bank registers? Your description of the IA-64 sounds more like bank selectable registers and similar --- the FP register stack of the i386 is an example that more people might be familar with. (Remember we're talking theory here, neither the ia64 nor the i386 use this mechanism.) Some architectures can refer to memory addresses using a register like notation. In fact I know of one architecture where every memory location can also be refered to using a register notation. Such an architecture would have zero raw registers. >> @itemize @bullet >> @item >> registers refered to by debug information >> @item >> user visible registers (specified by name) >> @item >> mode dependant registers (e.g., a 64 bit architecture in 32 bit mode may >> need to manipulate the 32 bits of 64 bit registers) >> @item >> memory mapped registers >> space. >> @item >> state dependant registers (e.g., bank registers) >> @end itemize >> >> Architecture methods then map the @code{NUM_REGS + NUM_PSEUDO_REGS} >> cooked registers onto raw registers or memory. > > > So pseudo registers are different from cooked registers? Or are they > the same? If they're the same, then distinguishing NUM_REGS and > NUM_PSEUDO_REGS sort of implies that NUM_REGS corresponds to the > number of raw registers. But that shouldn't be visible to the outside > at all. Pseudo registers? Beyond the constant NUM_PSEUDO_REGS, this section makes no reference to pseudo-registers. I guess I should add an historical note to the opening section pointing out that the constant NUM_PSEUDO_REGS originated from an earlier mechanism called ``pseudo registers''. While, for the moment, the constant remains, new targets use gdbarch register read/write and not pseudo registers. > >> cooked: [0..NUM_REGS) >> | \ >> | \ >> | \ >> | \ >> raw: RAW REGISTERS MEMORY > > > In other words, given that we're allowing cooked registers to be > computed arbitrarily from raw registers and memory contents, why not > dispense with pseudo registers altogether? The need for pseudo registers was dispensed with a year ago. Someone just needs to clean up the old targets and cleanup some edge cases .... As for NUM_REGS, that defines the number of registers in the raw register cache (note below). I'll add a comment mentioning the rationale behind direct mapping the first [0..NUM_REGS) registers. It was firstly a case of K.I.S.S. and secondly due to suspected limitations in the current GDB code - the constant NUM_REGS unfortunatly still determines far more than the number of raw registers. You may want to read the e-mail exchange between myself and RichardE as it contains all the gorry details. I think I'll also add a simplified version of the diagraram to the opening section. thanks for all the comments, enjoy, Andrew