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

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

RE: [avr-gcc-list] testsuite saga continues


From: Wouter van Gulik
Subject: RE: [avr-gcc-list] testsuite saga continues
Date: Mon, 4 Feb 2008 20:17:27 +0100

 
> Just a little note to let you know that the above change and other small
> cleanups have been committed to cvs.
> 
>  From the changelog:
> 
> - give more information at program exit
> - cleanup a lot of #ifdef's
> - change the timeout from cycles to instructions, because the simulator
> runs slightly faster this way
> - add a barrier for the stack at 0x60, that makes avrtest abort with
> stack overflow when crossed
> 

Yes I have seen it, and used it. My clz no longer passes the test. It bails
on stack overflow. But if I comment out the long long parts, all is ok.

> The next step will definitely be ELF loading support. With ELF loading,
> I can decode symbols like "__bss_end" to know where the stack overflows
> exactly or use "__stack" to know where the stack underflows. I can also
> do a more symbolic log, by decoding addresses to their symbol names.
> 

That would be very cool! Although a dump log at an abort might also be
useful when debugging testcases.

Some more thoughts about the smaller avr's. I did not intend to catch wrong
instruction, but I was aiming at finding bugs that are do not apply to the
mega series. Because if there are bugs in the less capable devices, it's
very likely to be in the avr backend, which is easier to fix.

Can't avrtest/gcc fake a avr2 device (e.g. at90s8535) with tons of flash and
ram? Just like you now fake huge amounts of external memory? 

Thanks for the good work!

Wouter





reply via email to

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