From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 871 invoked by alias); 18 Jul 2008 16:57:06 -0000 Received: (qmail 856 invoked by uid 22791); 18 Jul 2008 16:57:04 -0000 X-Spam-Check-By: sourceware.org Received: from mail.idnet.net.uk (HELO mail.idnet.net.uk) (212.69.36.63) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 16:55:38 +0000 Received: from [91.135.5.64] by mail.idnet.net.uk (GMS 15.00.3626/NU3963.00.7ca42f0c) with ESMTP id bsbogkba for gdb@sourceware.org; Fri, 18 Jul 2008 17:55:34 +0100 Subject: Advice on architecture with a very large register bank From: Jeremy Bennett Reply-To: jeremy.bennett@embecosm.com To: gdb@sourceware.org Content-Type: text/plain Date: Fri, 18 Jul 2008 18:13:00 -0000 Message-Id: <1216400133.3530.25.camel@thomas> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-AuthenticatedSender: jeremy.bennett.embecosm.com@idnet.net.uk X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00207.txt.bz2 I'm updating GDB for the OpenRISC 1000 architecture. This has 32 general purpose registers and nearly 25,000 special purpose registers (SPRs) - 12 banks of 2048. The special purpose registers cover processor status, MMU control (TLB's match registers, translation registers), caches, debug via JTAG etc. They are loaded and stored by two privileged instructions and are *not* memory mapped. How should I best handle these in GDB? Since they form part of the state of the machine, they should be visible. However if I declare them as registers (which they are), I presume regcache will be huge and performance terrible. I could add commands just to display and set SPR's (the current solution), but this then precludes their use in other GDB contexts. I also can't see how to implement this within the target operations structure, so that it would work via the Remote Serial Protocol. If anyone else has experience of architectures with huge register banks, I'll be very interested to hear how you deal with this issue. Thanks, Jeremy - Tel: +44 (1202) 416955 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: jeremy.bennett@embecosm.com Web: www.embecosm.com