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

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

RE: [avr-gcc-list] Re: Simulator for GCC Testing


From: Weddington, Eric
Subject: RE: [avr-gcc-list] Re: Simulator for GCC Testing
Date: Sun, 13 Jan 2008 19:06:01 -0700

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Andrew Hutchinson
> Sent: Sunday, January 13, 2008 6:39 PM
> To: address@hidden
> Subject: [avr-gcc-list] Re: Simulator for GCC Testing
> 
> 
> 
> I has resurrected my testsuite setup for AVR. Thanks Eric for 
> emailling 
> me instructions.
> 
> I want to use this to check my patches.
> 
> The setup  uses patched gcc files to run gcc tests thru the AVR-GCC 
> compiler. Using GDB and SIMULAVR for execution (if appropriate)
> 
> Now I'm running this under CYGWIN

Great! Let me know if there are any changes needed from the instructions
I sent you.

> There are a an awful lot of tests, of  which a large number are 
> inappropriate or otherwise misapplied to the AVR.

That's true. That's one of the tasks on my list (any help appreciated)
is to patch the GCC Regression Test to fix these tests, whether they
need to be disabled for the AVR, or fixed so they run correctly on the
AVR, and get those patches sent to GCC and committed.

Doing this will also go a long ways towards getting the AVR target in
shape and allows us to petition the GCC Steering Committee to make the
AVR a Secondary Platform. Having the AVR as a Secondary Platform means
that GCC will not be released unless the AVR target at least builds
correctly. As it stands right now, the AVR target is not a Primary or a
Secondary Platform. If the AVR target breaks (accidentally), then there
is no obligation by anyone to make sure that it is fixed before a
release happens. Right now, if a release happens and the AVR target
works, then that is due to any and all volunteers who work on the AVR
target to ensure that things work before a release.

I've talked to the Release Manager in person about the status of the AVR
target. When GCC releases 4.3.0 and work starts on 4.4, then I will
petition the GCC Steering Committee to accept the AVR as a Secondary
Platform. It has enough popularity (what with distributions on Windows,
FreeBSD, Linux, Mac OSX, etc., and at least the sheer number of
downloads of WinAVR), and there has been more people who are
contributing and concerned with the quality of the port. These issues
with getting the GCC Regression Tests fixed for the AVR target fit
within the overall quality of the port and is extremely important for
the future.

Anyway, that's the big overview. :-)
 
> To get things going quicker, I re-tried Avrora as a simulator  - last 
> time I tried (2004)  it would not load files correctly but 
> 1.6.0 seems 
> to have solved that. This simulator is not only quicker than 
> simulavr- 
> but I can avoid using gdb. So I can get more cpu cycles/real 
> time. ( I 
> can also limit execution time in terms of cpu cycles!)
> 
> Its not perfect, the breakpoints only list the address, not 
> the symbol, 
> or a breakpoint number. So I hacked test setup files to make exit and 
> abort jump to fixed address so that dejagnu scripts could figure 
> difference between pass/fail.
> 
> It's  also throwing  RAM read exceptions (outside of target address 
> range) - I didn't notice that with SIMULAVR - but I don't 
> know if that 
> is problem with gcc, Avrora or Simulavr!

If the only thing you changed was simulavr to avrora, then I would lean
towards avrora being the culprit.
 
> I still have to go back over the results to figure out if my setup is 
> fully correct.
> 
> The idea simulator for the testsuite is one that loads software and 
> setting from command line and runs it quickly - minimal I/O emulation 
> needed. Simple breakpoints - so that exit/abort can be 
> output. Control 
> of maximum execution time is desirable. For AVR, at least, I 
> do not see 
> a need to use gdb as front end for testing.  So Avrora is somewhat 
> attractive in this respect. I have yet to try simulavrxx.

Let us know what you find out! I agree that anything that helps speed up
the GCC Regression Test would be extremely useful!

Eric Weddington




reply via email to

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