From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12942 invoked by alias); 3 Dec 2001 05:22:45 -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 12919 invoked from network); 3 Dec 2001 05:22:43 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.114.42.213) by sources.redhat.com with SMTP; 3 Dec 2001 05:22:43 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id D29F53D59; Mon, 3 Dec 2001 00:22:28 -0500 (EST) Message-ID: <3C0B0C14.5040104@cygnus.com> Date: Sun, 02 Dec 2001 21:22: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: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: The REG_NUM and REGISTER_BYTES problem References: <3C084D16.4090205@cygnus.com> <20011202180304.A7998@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00006.txt.bz2 > Well, how will this affect pseudo registers that we can provide but > that the remote stub can not? I'm pretty sure there are some. Is the > intent that such registers "should not" be fetched? Hmm, yes, er, how can I put it? Pseudo registers are a figment of GDB's vivid imagination? Hmm, perhaphs not. The theory is that core-GDB delegates _all_ responsibility for the resolution of such issues to the target architecture. Or to put it another way, the target architecture is given enough rope to hang its self :-) Yes, there are going to be registers that should not be fetched by remote.c from the target. The trick is that register read/write should have already intercepted such register requests and mapped them onto real registers. (ok, I've simplified it a little :-) Think of it as: user -> register read/write (maps cooked to raw) -> regcache read/write -> target fetch/store -> target.c -> map regnum to target regnum provided register read/write is implemented correctly, the architecure is honky dorey. To give a tangeable example, consider i386's MMX. These 64 bit pseudo registers can be mapped onto 80 real FP registers. The register read/write function map's MMX N register onto FP register M. enjoy, Andrew