From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14356 invoked by alias); 12 Jul 2002 18:04:10 -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 14349 invoked from network); 12 Jul 2002 18:04:10 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 12 Jul 2002 18:04:10 -0000 Received: from localhost.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g6CI32Q01851; Fri, 12 Jul 2002 11:04:54 -0700 Received: by localhost.redhat.com (Postfix, from userid 469) id C2CF7107DB; Fri, 12 Jul 2002 13:59:30 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15663.6402.648639.635444@localhost.redhat.com> Date: Fri, 12 Jul 2002 11:36:00 -0000 To: Joern Rennecke Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: Unreviewed patches In-Reply-To: <3D2EC4B3.FDDB3D47@superh.com> References: <3D205F19.1B99290F@superh.com> <15648.31077.572892.886182@localhost.redhat.com> <3D208CF1.AB7AC45A@superh.com> <15648.51312.63195.689336@localhost.redhat.com> <3D20D12F.6AB9E865@superh.com> <15649.65211.660582.965251@localhost.redhat.com> <3D236046.4FAE0419@superh.com> <15662.14806.918730.224362@localhost.redhat.com> <3D2EC4B3.FDDB3D47@superh.com> X-SW-Source: 2002-07/txt/msg00276.txt.bz2 Joern Rennecke writes: > Elena Zannoni wrote: > > For the gdb sh-tdep.c part, I have a few comments. > > There is no need for a prototype. I removed all of those a few months back. > > Ok, I'll place the new function so that it needs no prototype. > But you have to keep in mind that that makes the call graph more > rigid, unless you like to move code around a lot. > Thanks. I did a major clean up recently, and things should be ok for a while. If I find out that I have to introduce a prototype in the future because there is no other reasonable choice, I'll revisit the decision then. > > You should just move the new function to before the gdbarch_init one. > > Instead of adding another enum, you should use > > > > struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch); > > and then > > tdep-><...>_REGNUM > > > > If you need new register numbers for the dsp case, just add > > them to the tdep structure. > > I think the stashing of constants into the tdep structure is basically > wrong. You separate the register names arrays from the literals > that describe their positions, and you replicate the literals > up to four times. The tdep structure and the sh_gdbarch_init > function are so large that you have lost track of the things that > really belong in tdep, like sh_show_regs, skip_prologue_hard_way, > and do_pseudo_register. If you look at other gdb ports, you'll > see that they put only variable stuff in tdep, and use enums > for constants. The sh gdb register naming scheme also doesn't > scale well, the names are again duplicated multiple times. > Tdep contains the things that change between different flavors of the architecture, when you say 'set architecture blah'. The register numbers belong to that category. ppc does the same. > I have a scheme that names each register just once, and enumerates > it only once - in an enum, of course. But I thought we should first > sort out the simulator <-> gdb and gcc -> gdb interfaces before we > start on the gdb internals. > Definitely, focussing on the interface issues is time better spent right now. Elena > -- > -------------------------- > SuperH > 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ > T:+44 1454 462330