From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19611 invoked by alias); 9 May 2002 19:49:52 -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 19604 invoked from network); 9 May 2002 19:49:51 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 9 May 2002 19:49:51 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4B1473DB9; Thu, 9 May 2002 15:49:58 -0400 (EDT) Message-ID: <3CDAD2E6.3080102@cygnus.com> Date: Thu, 09 May 2002 12:49:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joern.rennecke@st.com Cc: gdb@sources.redhat.com Subject: Re: [Fwd: Re: SH5 compact register numbering in gcc -> gdb interface] References: <3CD8F3EC.1FE421BB@st.com> <3CD97C16.6050801@cygnus.com> <3CDA76AA.16974781@st.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00088.txt.bz2 > Let me get this straight. > You want a unified simulator interface, not reusing register numbers > for registers with different sizes Since the SH1..SH4 numbers > are already assigned for a bunch of 32 bit registers, the SH5 > simulator register numbers will have to start after the SH4 ones, > i.e. the register numbers for the SH5 simulator have to be sparse > (have a large gap at the start). The reason I recommended doing something to the simulator register numbers was to detect problems when combining SH* gdb with a simulator in a specific mode. For instance, given a SIM modeling the SH4 ISA, it doesn't make sense for GDB to try to read SH5 hardware registers - the SIM doesn't have them. By assigning different sim_regnum's to each ISA, GDB/SIM can detect a conflict. There are other ways of handling this, I happen to think that this is the simplest. > Now you are saying that the remote protocol does not allow to start > the registers with a number other than zero, and the register numbers > should not be sparse. This isn't new. For a given ISA [0..NUM_REGS) are hardware/raw registers. Pseudo-registers can't be put before this. Making the number of registers sparse means having to iterate over gaps. > Thus, by unifing the register numbering in the SH1-4 / SH5 simulator > interface, we must make the register numbering SH5 simulator interface > different from the one in the SH5 remote interface. Yes. For GDB, having to do this is just another fact of life :-) > It appears to me that we make the entire mess even harder to maintain > this way. Why is having different register numbering for the same > processor for simulator / remote better than having different numbering > between the SH1..SH4 simulator vs. the SH5 simulator? Remember, GDB has a number of interfaces (sim, remote, dwarf2, stabs, mdebug, ptrace, ....) and (except for the remote protocol) each will have its own register numbering scheme. While trying to make all numbering schemes identical sounds good in theory it turns out to be impossible in reality. Hence, I think, pinning down specific interfaces is more important than trying to go for a single unified numbering scheme. Once remote.c has been ``fixed'' it will be possible to improve things though. enjoy, Andrew