This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unreviewed patches


Joern Rennecke writes:
 > Elena Zannoni wrote:
 > > 
 > > Joern Rennecke writes:
 > >  > Wed Jun 12 13:20:51 2002  J"orn Rennecke <joern.rennecke@superh.com>
 > >  >
 > >  > include/gdb:
 > >  >         * sim-sh.h: Add enum constants for sh[1-4], sh3e, sh3?-dsp.
 > > 
 > > Yes, sorry for the delay.
 > > 
 > > Is there any real reason to not just have one enum, which included the
 > > dsp registers as well?
 > 
 > Yes.  The values are supposed to stay the same, to retain compatibility.
 > Besides, you would need to re-design parts of the simulator to remove
 > the overlaps.
 > 


OK, I see what you are saying, but I don't think that removing the overlaps
from the gdb<->sim interface necessarily forces you to remove the overlaps
from inside the simulator.
It just cleans up the sim_fetch_register and sim_store_register code.

I am not sure I understand your claim about compatibility. You mean
older gdb's with new sims? That cannot happen. Or you mean the layout
of the registers that gdb has internally? That is staying the same
(and the 'g' packet layout stays the same as well) The thing you need
is to define a 'translation' step in gdb between gdb and sim register
numbering schemes.  Much the same as dwarf2_reg_to_regnum & friends do
between gcc and gdb.

 > > 	                 I mean, if the simulator didn't reuse register
 > > numbers for FP regs and DPS regs, then you could get rid of this ugly
 > > code in interp.c:
 > > 
 > >     else case 44:
 > >       if (target_dsp)
 > >         RE = val;
 > >     else case 45: case 46: case 47: case 48: case 49: case 50:
 > > [...]
 > >     case 26:
 > >       val = target_dsp ? A0 : FI (1);
 > >       break;
 > > [...]
 > > etc. etc.
 > > 
 > > And with that you could get rid of the target_dsp variable.
 > 
 > Definitely not.  The same 0xfxxx opcodes mean different things to sh3-dsp
 > and sh3e.
 > Using the same register number for fpscr and dsr is natural, since the same
 > opcodes are used to load/store dsr on sh3-dsp and fpscr on sh3e.
 > 

Ok, I see that the variable is used in the simulation of those instructions.
But that bears no relation with the interface we are trying to define here.

 > > I think the changes below depend on the cgen patches being accepted first.
 > 
 > They have.
 > 	

I don't see any replies to your message to the cgen/gdb-patches lists.

Elena


 > -- 
 > --------------------------
 > SuperH
 > 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
 > T:+44 1454 462330


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]