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

[Klaus Rudolph]

> 
> My preliminary ideas for that would be the following: a suite of small 
> C programs that contain a main() method that contains the various code 
> to be tested (i.e. method calls, various expressions, complex 
> branching, access IO registers, etc, etc) that cover a broad base of 
> functionality. A single global variable in the C program would receive 
> the ultimate result of that computation--for example the accumulated 
> value of a complex loop. Then when compiled, the memory location at 
> which that global variable is extracted from the symbol table 
> information in the binary. That address and the expected value (which 
> is only set to the correct value by in-program tests) can be passed to 
> the simulator through the test file (as it is now--simply comments with 
> @Result = <list of state predicates>).

That is excact what I sugessted ten mails ago :-) To provide the result you 
can also use
the elf file, there must no comment and a parser. simply use a constant and
put it somewhere in the memory. The symbol would be resolved and thats it. 
No dependencies to the command line options of the compiler, no 
side effects from libraries. All is tested again and again and the result,
the really visible outgoing information is tested and nothing else.
This is in my opinion, the simpliest and also the only full automatic
solution.
All others seems to be to much handcrafted and take to long time
to validate the results which means directly that nobody will check for
them.


Bye
   Klaus

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