[Top][All Lists]

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

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

From: E. Weddington
Subject: Re: [avr-gcc-list] binutils/.../testsuite/avr
Date: Fri, 03 Dec 2004 14:07:44 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Klaus Rudolph wrote:

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
for binutils (and gcc) is that there isn't a method to run it, i.e. where is there a
that works well enough to run the test suite?

There's simulavr, it's successor: simulavrxx, avrora, and I think that's
it for (open source) simulators. None of these are in a state that can run an automated
(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
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
because the same input kust result int the same output :-)

I'm sorry, I did not mean to imply that simulavrxx could *not* fulfill the role. It certainly could be made to do so, I suppose.

I am not at all familiar with what is required to run automated tests in binutils and gcc for the avr target. Other embedded targets, for example arm, seem to have a simulator that is generated that is stored with the GDB project and is used to run these testsuites. At least I *think* that's how it works.

What would be great is if the automated testsuites in binutils and gcc could be executed in some manner for the avr target, with a simulator. That way test results could be reported back to binutils and gcc. I think this would help to "raise the profile" of the avr target in the gcc project. However, I do not know enough to say what needs to be done, or how to begin. But this is definitely an area that could use volunteers.


reply via email to

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