From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12188 invoked by alias); 20 Jul 2002 20:41:03 -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 12170 invoked from network); 20 Jul 2002 20:40:54 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 20 Jul 2002 20:40:54 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 571703EE3; Sat, 20 Jul 2002 16:40:49 -0400 (EDT) Message-ID: <3D39CAD1.3060106@ges.redhat.com> Date: Sat, 20 Jul 2002 13: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00211.txt.bz2 > The example of the IA-32's MMX and FP registers is a great example for > this. The MMX registers, MM0--MM7, and the FP registers, > ST(0)--ST(7), actually refer to the same set of eight eighty-bit > registers, R0--R7. A reference to the floating-point register ST(i) > becomes a reference to R((TOP + i) % 8), where TOP is a three-bit > field in the FPU status register. But a reference to the MMX register > MM(i) becomes a reference to the lower 64 bits of R(i) (which would be > the mantissa of some ST(i)). (In the current code, ST(I) and not R(I) is stored, so we end up with MM(I) == regcache(FP0 + (TOP + 1) % 8) :-( I'm almost ready to dust off the patch that does this.) Anyway, I think the above example highlights why I see it as important to use terms like ``hardware'' or even ``physical''. Those terms drag the GDB developer's eye away from those glossy user level ISA specs, and instead focuses their attention on the underlying hardware model used to implement the userland ISA. While well above the level of flip-flops, it is still a clear step below the ISA that a typical native GDB user will be aware of. (A PPC refers to the ``operating environment architecture''). For the i387, the programmer spec is all about a register stack, yet the underlying hardware uses a block of 8 registers and an index. It is the latter, the lower level hardware details, that the GDB developer should focus their attention on when deciding the contents of a register cache. > processors, then there are all sorts of confusing questions that > brings up --- e.g., "How in the world would GDB get hold of the state > of the raw flip-flops on a native Linux system?") Clearly that isn't low level enough! GDB needs to be getting down to the level of quantum effects :-^ There is a bit of irony here mind. The i386 Linux kernel correctly provides a low-level hardware view of the i387 registers (the 8 register block and the index). Current GDB however, by failing to abstract the raw register cache at that same low level, has ended up suffering from a series of obscure FP vs THREAD related register corruption bugs. enjoy, Andrew