From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15243 invoked by alias); 12 Apr 2002 16:45:02 -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 15200 invoked from network); 12 Apr 2002 16:44:59 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 12 Apr 2002 16:44:59 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 43D113CD8; Fri, 12 Apr 2002 12:45:05 -0400 (EDT) Message-ID: <3CB70F11.6010609@cygnus.com> Date: Fri, 12 Apr 2002 09:45:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joern.rennecke@st.com 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> <3CB6AD19.CCDD835A@st.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00459.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. Until the sim works, GDB probably won't add the code :-) The infrastructure is there. > 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. Strictly speaking GCC does re-number the interface between GCC and GDB. .stabs and dwarf2 debug info can have different register numbering for the same ISA/ABI. Fortunatly GDB has mechanisms for handling this. As for hardware monitors, I'm not sure. I do know that the MIPS has more G packet formats than I've had hot dinners. Here, unfortunatly, the mechanisms GDB needed to handle this are still work-in-progress. As for the SIM, there is REGISTER_SIM_REGNO. However, that may not be sufficient. > 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. Formalizing would be a better word. So that GDB and the SIM can agree on the register numbers and their sizes without needing to know the others internals. Andrew