> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Andrew Hutchinson > Sent: Sunday, January 13, 2008 6:39 PM > To: [email protected] > 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
