Re: test result code was Re: [Simulavr-devel] avrtest and simulavr vs simulavrxx

[Joel Sherrill]

Klaus Rudolph wrote:
> > This is WAY overkill if all you want is the exit status.  This
> > is why avrtest has magic ports for exit and abort.  You write
> > the exit code to the exit magic port and poof exit(value) is
> > called.  This is the way all the simulators in gdb work.
> >
> >     
>
> ???
> gdb can read the memory direct from simulator. So there is no need for 
> an elf file nor an special exit port.
> ???
>
> Can you explain what is an exit port please. I think I have a complete 
> misunderstanding of this topic.
>
>   
All of the simulators in gdb have a special syscall call mechanism
where you can access the host.  The intent is to have enough
support to make the simulators easy to run and use with the
GNU tools test suites -- in particular gcc.

Just as simulavrxx already has magic ports for debug IO,
the GDB simulators also have a way for the application running
on the simulator to force an exit() with a specific return value.

The key is that GCC doesn't care or know about specific CPU
models -- only the CPU core (e.g. multilib variant).  The peripherals
are irrelevant as are interrupts.  So having "synthetic CPU models"
which correspond to a CPU core and simulator specific peripherals
which ease testing is perfect.  For example, (if my AVR knowledge
is right) from GCC's perspective, these are the same:

64KB/100-pin version: ATmega640 
<http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega640>
128KB/100-pin version: ATmega1280 
<http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega1280>
256KB/64-pin version: ATmega2561 
<http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega2561>
256KB/100-pin version: ATmega2560 
<http://www.atmel.com/dyn/products/product_card.asp?PN=ATmega2560>


The key features you need in a simulator for gcc testing are:

+ console output mapped to stdout
+ time limit on execution
+ enough memory to run tests
+ easy way to get exit status from simulator.

The last isn't even needed by the DejaGNU tests since the
framework has a way to print the status on exit().

So there is tool testing and application testing.  For
application testing, the fidelity of the peripherals is
important.  But irrelevant for tools testing -- you want
that to be simple.

avrtest has three magic ports added by someone for
tools testing -- out char, exit, and abort.  For avrtest,
the code in question is easy to read:

===========================
static void data_write_byte_raw(int address, int value)
{
   // add code here to handle special events
   switch (address) {
       case STDIO_PORT:
           putchar(value);
           return;
       case EXIT_PORT:
           leave(value ? EXIT_STATUS_ABORTED : EXIT_STATUS_EXIT, "exit 
function called");
           break;
       case ABORT_PORT:
           leave(EXIT_STATUS_ABORTED, "abort function called");
           break;
   }

   // default action, just store the value
   cpu_data[address] = value;
}

===========================

I have implemented the functional equivalent of the above
for simulavrxx.
> Thanks!
>
>
>
>   
No problem.


--
Joel Sherrill, Ph.D.             Director of Research & Development
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985