From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31334 invoked by alias); 29 Apr 2002 17:47:54 -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 31314 invoked from network); 29 Apr 2002 17:47:52 -0000 Received: from unknown (HELO localhost.redhat.com) (66.31.105.161) by sources.redhat.com with SMTP; 29 Apr 2002 17:47:52 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 65C0B3D6D; Mon, 29 Apr 2002 13:47:54 -0400 (EDT) Message-ID: <3CCD874A.8010801@cygnus.com> Date: Mon, 29 Apr 2002 10:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020424 X-Accept-Language: en-us, en MIME-Version: 1.0 To: joern.rennecke@st.com Cc: bje@redhat.com, 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> <3CB70F11.6010609@cygnus.com> <3CBA940B.B99F0E4C@st.com> <3CBF73A3.2090409@cygnus.com> <3CCD81CD.CBAC3A62@st.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg01128.txt.bz2 >> >> 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. > >> > >> > >> > They only need to know if the program is for an sh5 or an earlier processor. >> > This information is readily available from the elf flags (the lower five bits > >> Having just looked at a different target (similar problem), I think >> having a single file that assigns different number ranges to the sh4 vs >> sh64 registers would be best. That would make it easy to detect things >> like trying to fetch an SH64 register from the SH4 sim. > > > Using the current raw / pseudo-register distinction, that would lead to funny > artifacts: the sh and sh64 raw registers would all come first, and only then > the can the pseudo registers follow. Um, these sim register numbers are separate to GDB's internal ``raw'' registers (and don't have anything to do with pseudo-registers). GDB will need to map any internal register number onto the published sim register number before fetching a sim register. Given an enum sim_sh_regnum { ... sim_sh64_r0, ...sim_sh_r0, ... } (who knows if r0 exists on the sh). If GDB thinks it is talking to an sh64 sim it would ask for ``sim_sh64_r0'', on the other hand if it things it is talking to an SH4 or prior, it would ask for sim_sh_r0. If GDB and SIM think differently (one is sh64 and the other is SH) then, I think, the only immediate objective is to not dump core. Andrew