From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12715 invoked by alias); 12 Apr 2002 09:57:58 -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 12675 invoked from network); 12 Apr 2002 09:57:56 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 12 Apr 2002 09:57:56 -0000 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id DE8284BD8; Fri, 12 Apr 2002 09:57:53 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 223C063FC; Fri, 12 Apr 2002 09:52:07 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1E9041845; Fri, 12 Apr 2002 09:52:06 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 16vxiv-0002oN-00; Fri, 12 Apr 2002 10:52:05 +0100 Received: from [164.129.14.84] (helo=st.com) by masterwort with asmtp (Exim 3.22 #1) id 16vxiu-0006A9-00; Fri, 12 Apr 2002 10:52:04 +0100 Message-ID: <3CB6AE86.4E02E81D@st.com> Date: Fri, 12 Apr 2002 02:57:00 -0000 From: Joern Rennecke Reply-To: joern.rennecke@st.com Organization: SuperH UK Ltd. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney Cc: Ben Elliston , gdb-patches@sources.redhat.com Subject: Re: SH5 simulator contribution References: <15451.47633.743434.331956@scooby.brisbane.redhat.com> <3C5F55F3.2030807@cygnus.com> <15455.24394.87381.934711@scooby.brisbane.redhat.com> <3C5F66BB.50001@cygnus.com> <15455.31263.847272.160235@scooby.brisbane.redhat.com> <3C6008DF.5020702@cygnus.com> <15456.16085.191791.112025@scooby.brisbane.redhat.com> <3C6088B3.7080702@cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00449.txt.bz2 Andrew Cagney wrote: > The sim/sh simulator has a specific register name / number / size > mapping and sh-elf-gdb knows how to use it. > > This new sim/sh5 simulator has a different register / name / size > mapping and this difference is covered up by GDB. (I note the addition > of the sim-sh64.h file which is in itself a very good move). Actually, the difference is not covered up by gdb. The compiler emits different register numbers when compiling for sh5 or shcompact than when compiling for sh1..sh4. The sh64 simulator matches the numbering scheme for the sh5 / shcompact targets, while the old sh simulator matches the numbering scheme for sh1..sh4 targets. When you try to use gdb with the sh64 simulator as submitted so far on an sh4 program (i.e. set a breakpoint, display registers), it just falls over. In order to have a unified interface between gdb and the simulator, you would have first to introduce a translation step in gdb to translate the old register numbers for sh1..sh4 programs to the new scheme, and in the old simulator translate it back (the latter is easy, since there is already a translation going on in sim_store_register / sim_fetch_register). You can't just change the numbering in the interface between gcc and gdb, because that would break binary compatibility. And you also can't change the interface between gdb and hardware monitors. So I don't see that you gain anything by unifying the numbering scheme in the gdb <-> sim interface, as it would be at odds with the interface to gcc and the hardware interfaces. > The MIPS (unintentionally) went down this path and ever since the MIPS > has been trying to claw its way out of the resultant mess :-( Given Could you be more specific what you are trying to avoid? > this, I think it would be better to just eliminate one of the > simulators. Failing that, ensure that at least the two simulators > complied to an identical register name/number/size interface. > > Would it possible to get this new SH simulator to support the sh-dsp > instructions (there can't be that many of them) so that the old > simulator can be retired? It's not so much the number of sh-dsp instructions - although it's a pretty large one, there is special code in the simulator sources to automatically generate the descriptions from a smaller number of templates - but the fact that they are of variable length, and use three different address spaces. I understand that cgen would need some non-trivial infrastructure work to handle this. The new simulator also has no SH1 support, although that should be comparatively simple to add. > More as a wish list, would it also be possible to have separate but > integrated simulators for at least the few most recent SH variants - > like mn10300 and am33. I suspect this simulator was generated so it > shouldn't be too hard. SH4 and SH5 are the most recently released SH variants. So if the new simulator could be fixed to handle debugging of sh4 programs - I hope that is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new instead of shcompact_init_cpu into sh4_mach - than this goal would be fulfilled. -- -------------------------- SuperH 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ T:+44 1454 462330