From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26378 invoked by alias); 21 Jul 2002 16:41:10 -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 26366 invoked from network); 21 Jul 2002 16:41:08 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 21 Jul 2002 16:41:08 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0355E3EF9; Sun, 21 Jul 2002 12:40:59 -0400 (EDT) Message-ID: <3D3AE41B.10201@ges.redhat.com> Date: Sun, 21 Jul 2002 09:41: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00216.txt.bz2 > No, I think we need to draw the GDB developer's eye *to* those glossy > user-level ISA specs. :) Figure 8-1 --- the first diagram in the > chapter titled "Programming with the X87 FPU" --- has R0 -- R7 right > there. The second diagram, figure 8-2, shows how the TOP field > affects the relationship between ST(i) and Ri. The fact that there is > a fixed set of registers accessed as a rotating stack is very much > part of the ISA documentation. 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. Taking a step back. Cooked registers are at the level of the user and/or ABI. Raw registers are at the level of the underlying system/hardware. The GDB developer needs to be familar with both. More importantly, and as I mentioned last time, we need to be very careful to ensure that the GDB developer looks beyond that user model and on down to the lower level details of the architecture. > 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. enjoy, Andrew (1) The ia32 manual set is badly organized. Try figuring out the full set of registers (user and system) on, say, a p4.