AVR testing [was: Re: Revised release criteria for GCC 4.0]

[E. Weddington]

Hans-Peter Nilsson wrote:

>On Wed, 15 Dec 2004, E. Weddington wrote:
>  
>
>>Ok, sure. But realistically, it's going to be the AVR port developers
>>who will be running the testsuite, and they're already familiar with
>>avr-libc (I'm excluding the RTEMS folks for this argument).
>>    
>>
>
>You're still missing the point that the simtest-howto.html stuff
>is generally not for port maintainers but for *other* GCC
>developers.
>
>  
>
At this point I don't care *who* tests the AVR as the GCC testsuite 
can't currently be executed for the AVR in any configuration.
Something is better than nothing. Normalisation can happen later, when, 
I'm sure you can understand, there's enough volunteer time to do it

>>So, from what I gather with that statment, is that using newlib is just
>>a convenience; there's nothing inherent in it that is required for
>>testing with a simulator?
>>    
>>
>
>Correct.  Of course, you need for newlib to generate and for the
>simulator to have special calls for e.g. file operations and
>memory allocation.
>  
>
Are you talking about file operations and memory allocation for the 
target? The AVR is an 8-bit RISC microcontroller; it's not going to be 
hooked up to a filesystem (normally), and only has a primitive malloc.


>  
>
>>Hmm, that's what I was hoping to find out, documentation for those types
>>of simulators. I've seen SID <http://sources.redhat.com/sid/> and GGEN
>><http://sources.redhat.com/cgen/>, but does anybody know what is
>>currently being used to develop those simulators in the sim directory?,
>>what should be used?
>>    
>>
>
>If there's already an AVR simulator, you shouldn't start from
>scratch; just connect it to the sim framework.  
>
Ok, that's what I needed to know to get things up and running. I forgot 
that there is a second simulator for the AVR, Avrora:
<http://compilers.cs.ucla.edu/avrora/>. The main author has expressed 
some interest in hooking up to the framework in GDB.

>See ppc, arm or
>sh simulators for instance.  No documentation, but plenty of
>source code. 
>
Thanks for the pointers.
Eric