From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4939 invoked by alias); 29 Sep 2003 17:25:26 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4932 invoked from network); 29 Sep 2003 17:25:25 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Sep 2003 17:25:25 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B24822B89; Mon, 29 Sep 2003 13:25:26 -0400 (EDT) Message-ID: <3F786B06.2090601@redhat.com> Date: Mon, 29 Sep 2003 17:25:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: LaPonsey Brian-ra4951 Cc: gdb-patches@sources.redhat.com Subject: Re: mcore registers References: <15BB35FC418BD511868500D0B7B916B108A35017@zuk07exm02.sps.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00629.txt.bz2 > I have written a gdb stub for mcore-elf, and in my efforts to improve it I have noticed that gdb defines too many control registers for the mcore chip. Despite having a 5-bit field in the control register move instructions, there are not actually 32 control registers on the mcore. All the existing mcore designs, either current or planned, have only 13 control registers. The gdb source code defines all 32, but cr13..cr31 don't actually exist. > > It speeds up the stub not to have to report the status of these phantom registers over the serial line. Patching them out of gdb also allows the stub to keep its RAM requirement below 1K. > > My question is, would it be advisable to make this change to the gdb mainline? I realize that there will always be unintended consequences of such a patch. Any thoughts? Can you post the output from "maint print registers"? If these registers are last, the stub can send back a short register packet (such a packet implies that remaining registers are zero, gdb shouldn't send a longer packet back to the stub). It may also be possible to run length encode (phrase?) the "x" indicating that the the missing registers are not available. If GDB, without other changes, dropped those registers, compatibility with existing stubs would be broken. Andrew