This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: GCC 4.3 Platform List


Michel Lespinasse wrote:
On Thu, Sep 21, 2006 at 08:43:53PM +0100, Richard Sandiford wrote:
I take David's point about mips{,el}-linux-gnu being another alternative.
I suppose mipsisa64-elf has the advantage of being a simulator target
than anyone can test.

I'm not familiar with the kind of testing you guys usualy do on simulators - however since this is the second time it's mentionned I should say that mipsel binaries run just fine in the gxemul simulator.

I've recently done a whole debian etch installation that way -
see http://zoy.org/~walken/gxemul-etch/HOWTO.html for the instructions.

Hope it helps. If you can point me to a page describing what you mean about
simulator testing I'd be interested too :)

Some architectures have very robust simulators built into gdb. On those architectures,
a simple toolset of binutils, gcc, newlib, and gdb can run all the gcc tests which do
not require tasking or filesystem. It is an easy bare metal environment that is easy
to build, use and debug on. It is completely free and anyone can reproduce it.


For RTEMS simulator testing, we like a simulator to have a way to generate a
regular clock tick interrupt source. That lets us add tasking with time services.
Plus RTEMS has an easy to use in-memory filesystem which can be used
to help pass even more test cases. The advantage as you know is that simulators
are "cheap reproducible hardware." And using targets like mips-elf that is
close to the metal eases the complexity burden of configuring any OS on a
simulator.


--joel
Cheers,



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