avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] binutils/.../testsuite/avr


From: Klaus Rudolph
Subject: Re: [avr-gcc-list] binutils/.../testsuite/avr
Date: Fri, 3 Dec 2004 08:17:56 +0100 (MET)

> On Thu, Dec 02, 2004 at 08:16:41AM -0700, E. Weddington wrote:
> > Please note that probably one of the reasons why there isn't an avr
> testsuite 
> > for binutils (and 
> > gcc) is that there isn't a method to run it, i.e. where is there a
> simulator 
> > that works well enough 
> > to run the test suite?
> > 
> > There's simulavr, it's successor: simulavrxx, avrora, and I think that's
> about
> > it for (open source) 
> > simulators. None of these are in a state that can run an automated
> testsuite 
> > (for either binutils 
> > or gcc). I would think that this needs to be addressed first.

Sorry, why should simulavrxx not be able to run automated testsuites?
The simulator has an scripting interface (tcl/python/... all what swig can
generate!), it is able to read elf files
it executes code also with ram/ext-ram eeprom and flash configurations
also with nearly exact timing and results could also be generated like
interrupt statistics and a lot more. And the gdb interface is also still
alive
where all intermediate steps could be watched in detail also automated like
the regressin tests from Theodore show. What is missing for automated
testsuite? No problem to implement this. Please give me a detailed
requirement list
and I will implement this. (I hope the list not so long :-)))
For a faster comparion maybe a elf file write could help where the
ram/flash/eeprom is written out and could be compared again a given 
file. If that is needed or any other add on or change, let me know.
  
> 
> This is where I further reveal a lack of familiarity with gnu toolchain
> development conventions, I'm afraid. Given that it is the target cpu
> that runs the code which the assembler has created, it would seem quite
> sufficient to confirm that the assembler generates correct opcodes for
> all legal input.

That is what the simulator is good for. Simply check the results of a run.
The way how the result was generated is not interesting and can differ
from according to compiler command line option. OK, for binutils it doesn´t
matter
because the same input kust result int the same output :-)

Bye
   Klaus


-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++


reply via email to

[Prev in Thread] Current Thread [Next in Thread]