|
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
[Prev in Thread] | Current Thread | [Next in Thread] |