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

[Klaus Rudolph]

Hi all,

could we please make the mails a bit shorter. It make no sense 
to write something somewhere in some mails :-)
I have only a very slow internet access and I would archive all mails from
the list. But if each mail contains all text from the thread that make no
sense.

http://www.netmeister.org/news/learn2quote.html

Thanks
   Klaus





> Ben L. Titzer wrote:
> 
> >
> > On Dec 3, 2004, at 1:07 PM, E. Weddington wrote:
> >
> >> 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
> >>>>>
> >>>> 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 :-)
> >>>
> >>>
> >
> > This already exists in Avrora. If you look at the source distribution, 
> > there is a directory avrora/tests that contain assembly language tests 
> > that have at the beginning of them a little description of what the 
> > state of the program should be when it exits (reaches the branch 
> > instruction). The simulator has a little test harness inside 
> > (avrora.test.SimulatorTestHarness) that picks up these values, loads 
> > the program, runs it, and collects together the results of executing 
> > all the runs.
> >
> > You can try by going to the avrora/tests directory and running:
> >
> > java avrora.Main -action=test *.asm
> >
> > -B
> >
> > P.S.
> > I believe that it is in sufficient state to do this for gcc / 
> > binutils. If not, it is easy to write a new TestHarness class that can 
> > load a different type of file, a different type of test case, etc.
> >
> 
> It looks like (from earlier posts) that a testsuite for binutils is 
> normally done without a simulator, and that there are a couple of people 
> working on it.
> 
> What would be great is to see what it would take to put together a 
> testsuite for GCC for the AVR target. It would be nice to be able to 
> catch regressions in the AVR port as early as possible.
> 
> Eric
> 

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