Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.

[Georg-Johann Lay]

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