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: SH5 simulator contribution


> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> 
> Andrew> The mn10300 simulator binary, contains a simulator for both
> 
>   Andrew> :model:::mn10300:mn10300:
>   Andrew> :model:::am33:am33:
> 
>   Andrew> Which simulator to use being selected at run time.  The other two are 
>   Andrew> v850 and MIPS (not d10v).   This jells well with GDB which also supports 
>   Andrew> those same architecture variants.
> 
> This could certainly be done.  There is only one cpu variant right now
> ("sh5").


That would be very useful.  This means that when you say it supports the

sh2..sh4 it is through the backward compatibility of the instruction set

architecture. This explains why the config tweeks only enable the

simulator when sh64-elf.


If I understand the sim/sh simulator correctly, it currently generates 
an sh-dsp sim which is backward compatible with sh2-4 (sh1?) but not 
with sh5.  This means that the new sh5 simulator is not a drop in 
replacement for the existing simulator (it lacks sh-dsp).

Unless the new simulator gains sh-dsp support, the sim directory will 
need to be configurable so that the user can select either the DSP xor 
the SH5 simulator.  That, I suspect, is going to get messy.  I think GDB 
should be able to assume a single SH remote-sim interface but here, I 
suspect, it is currently contending with two different interfaces :-(

Andrew


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