Paulo Marques schrieb: > Georg-Johann Lay wrote: >> Georg-Johann Lay schrieb: >>> With the avrtest simulator, I observe the following problem with the >>> -m option (max instruction count): >>> >>>> avrtest var-expand2.exe -mmcu=avr51 -m 1019948 >>> exit status: TIMEOUT >>> reason: instruction count limit reached >>> program: var-expand2.exe >>> exit address: 000318 >>> total cycles: 1483103 >>> >>>> avrtest var-expand2.exe -mmcu=avr51 -m 1019949 >>> [...avrtest hangs...] >>> >>> So there is a barrier: for all -m values >= 1019949 avrtest hangs, for >>> -m <= 1019948 avrtest stops as desired. >>> >>> I am using avrtest as of >>> http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/ >>> >>> All this blocks my work on avr-gcc, because I use avrtest as simulator >>> to run regression tests. FYI, I attached the avr-elf32 executable >>> var-expand2.exe (as tar, because mailing list rejects .exe). >>> >>> Is there a place that hosts updated versions of avrtest or is there a >>> site with more stable simulator that can run avr regression tests? >>> >>> Thanks for any hints on that. >> The problem is in avrtest.c:335 >> >> static int data_read_byte_raw(int address) >> { >> // add code here to handle special events >> >> if (address == STDIO_PORT) >> return getchar(); >> >> return cpu_data[address]; >> } >> >> address happens to be 82 which equals STDIO_PORT, therefore avrtest >> waits for input. I removed the if and avrtest works as expected; the >> test program hits ABORT in the remainder. > > This "happens to be" is quite strange. If this is happening I would > expect the var-expand2 program to have a bug and is actually reading > stdin for some reason. > > Or maybe you are compiling the test suite for a cpu model that has RAM > at those adresses? The last time I ran the test suite I was compiling > for an atmega128 IIRC.
A program that goes wild does such weird things, even if there is *no* RAM there :-) For some variations of the test case avrtest detects a stack overflow, but for the exe you find attached avrtest does not see a stack overflow. > BTW, I was just looking at the repository and it seems that my last > change to implement cycle counters (very useful for benchmarking) that I > thought I committed is not there. Did I forgot to commit or did the > repository went back in time at some point? I don't know anything about avrtest repository/development. I just was happy to find the code somewhere in the abandoned WinAVR. As I wrote, I don't know if anyone still improves avrtest, what it development state/schedule is or where it is hosted. That version of avrtest has a cycle/instruction counter as you can see in the output above. Johann _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list