avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Problems with avrtest simulator and avr-gcc testsuite.
Date: Tue, 19 Apr 2011 21:01:09 +0200
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Paulo Marques schrieb:
Georg-Johann Lay wrote:

Paulo Marques schrieb:

[...]
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.


Ah! If this only happens for really bad bugs, we could either place a
timeout there or use a command line argument to disable stdin altogether
(maybe even exiting with ABORT in case the code tries to read stdin).

A command line option to deactivate stdin would be good. avr is not on a hosted environmant, there is nowhere input could come from.

ABORT is a good idea, with an appropriate "reason".

Besides that, avrtest could abort on:
- reading from any reserved location
- writing to any reserved location (except the virtual ports EXIT_PORT, STDOUT_PORT, ABORT_PORT.

this includes read/writes to GPRs via their memory address.

To check for reserved access code like this should perform well

int a = ((int) address) -32;

if (a < 0
    || (reserved_mask & (1 << a)))
  abort();

or just initialize a small lookup table for reads/writes.

The writer will already have handled the virtual ports, so the LUT for reals/writes may be same.

Johann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]