Re: Unreviewed patches

[Elena Zannoni <ezannoni@redhat.com>]

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