From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2381 invoked by alias); 24 Jul 2002 00:34:19 -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 2350 invoked from network); 24 Jul 2002 00:34:17 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 24 Jul 2002 00:34:17 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AFEAB3E5D; Tue, 23 Jul 2002 20:34:16 -0400 (EDT) Message-ID: <3D3DF608.8010403@ges.redhat.com> Date: Tue, 23 Jul 2002 17:34: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> <3D39954D.1020306@ges.redhat.com> <3D39CAD1.3060106@ges.redhat.com> <3D3AE41B.10201@ges.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00242.txt.bz2 >> I was talking generally. >> >> However looking at specific manual set(1) >> (http://developer.intel.com/design/pentium4/manuals), vol1 is the user >> stuff; vol3 is the system stuff. The GDB developer needs to look >> beyond vol1 and and into vol3. Vol1 8.1.10 Saving the x87 FPU's State >> with the FXSAVE Instruction, for instance, just points the reader at >> volume 3. In addition, the GDB developer ends up studying kernel >> interfaces and too often (ulgh!) kernel sources. > > > No, everything I cited was in volume 1, the user's manual set. The > diagrams explaining the underlying fixed registers and the rotating > names for them are in the "user stuff" manual. Sorry, I'm lost here. I was working my way through volume one and found, for some of the FP register stuff, it directed the reader to volume three. Too completly understand the i387 FP stuff (for the P[34]) I need to [re-]read chunks from both the user and the system volumes. Remember, my point was that the GDB developer needs to look beyond the user level documentation and on, into the system level documentation, and even kernel sources when designing GDB's register cache. Even for the above case, that is true. > I'm still trying to get a handle on your intent, though. In a case > like MIPS III (an ISA with 64-bit registers) running o32 (an ABI which > only uses the lower 32 bits of each register), would you suggest that > printing registers in the usual way should show the full 64 bits of > the register, or only the lower 32 bits? Sorry, I'm again lost. I earlier wrote (note edits): ``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 [cooked] views of the same [raw] register. When o32 debug info indicates a value in two adjacent [cooked] registers, it is refering to 32 bit and not 64 bit registers.'' I'm not discussing which of these should be printed since that is outside of the scope of this discussion. > For the rest, all I'm saying is that the text you've written fails to > draw the distinction you need to make. The term "hardware registers" > applies equally well to ST(0) and R0. I've suggested a better way to > make the distinction in the rego document, i.e., by giving examples > showing how real architectures might use the distinction. If you'd > like me to do that, just let me know. So "hardware" is as problematic as "physical"? What you're telling me is that I should avoid all such terms, right? >> > As a sanity check, assuming that SPARC register windows are analogous: >> > the SPARC ISA spec talks about register windows immediately, as well. >> > Figure 2 in the chapter on Registers shows "Three Overlapping Windows >> > and the Eight Global Registers". (For some reason, that makes me >> > think of Goldilocks and the Three Bears.) > >> >> Just FYI, an example involving the SPARC is on my things todo list for >> frames. It turns out that the OS for a register-window architecture >> typically flushes all but the inner most window to memory before >> transfering control to GDB. Consequently the only raw registers that >> GDB sees are those that are innermost. It is the frame, and not the >> register cache code, that needs to handle this one. > > > Yeah, since there aren't any underlying protocols I know of that > actually give you all the SPARC register windows directly, the SPARC > would not be a good second example. Perhaps the IA-64 with its > rotating registers for software-pipelined loops? If this section needs an example then (given MarkK's observation about the i387) then either d10v's two stack pointers or the SH's bank registers. Neither of these are especially complicated. Andrew