From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18563 invoked by alias); 1 Dec 2001 03:23:05 -0000 Mailing-List: contact gdb-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18542 invoked from network); 1 Dec 2001 03:23:04 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.129.200.2) by hostedprojects.ges.redhat.com with SMTP; 1 Dec 2001 03:23:04 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id B558D3D4B for ; Fri, 30 Nov 2001 22:23:02 -0500 (EST) Message-ID: <3C084D16.4090205@cygnus.com> Date: Sun, 25 Nov 2001 12:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: The REG_NUM and REGISTER_BYTES problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00248.txt.bz2 Message-ID: <20011125124400.i80tzciaXD_qfhPXDvzyVoXty72JmbbvDK22xLl_X0E@z> Hello, This is one of those ``in the beginning there was a VAX and life was good'' stories. Rather than start that way, lets try something different, in the beginning there was an m68k, er no, never mind ... Each GDB architecture defines two constants: NUM_REGS -> number of ``real registers'' REGISTER_BYTES -> number of byte the real registers occupy Simple eh? The problem is that this pair is very heavily entrenced in the way GDB views the world - they have come to mean a lot more. For instance: o A G packet is REGISTER_BYTES in size and can contain only NUM_REG registers. If, for some reason, you have a lot of ``real registers'' (i586 has the potential for 4 billion) then you're a bit stuffed. o The regcache is REGISTER_BYTES in size. o The generic inferior function call code assumes that, to save the target state, it just needs to slurp REGISTER_BYTES from the target stack and it can fetch any NUM_REG from that saved state. If you only think a subset of those registers should be saved or if you want to save both registers and memory then your out of luck. These problems come to a head when you try to do things like: o increase the number of ``real registers'' with out increasing the G packet size. o increase the size of the regcache via REGISTER_BYTES without forcing up the size of that G packet. o Add registers that you don't want saved/restored. To address this, I intend changing regcache and remote.c so that they treat all registers equal (don't differentiate between real and psuedo registers). Instead, regchace reserves space for all of them, and remote.c will fetch any of them when so asked. Exactly what to do with all that potential regcache space being the responsibility of the target architecture. By doing this, the immdiate restriction of not being able to expand the number of registers is lifted. While some of REGISTER_BYTES and NUM_REGS special effects will remain, they won't be causing GDB's ability to handle large register sets. Thoughts? Andrew