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

[Paulo Marques]

Wouter van Gulik wrote:
> > [...]
> > 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.

Can you elaborate on that? What exactly are you calling a dump log?

> 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? 

That probably won't work because (IIRC) smaller parts don't have the JMP 
and CALL instructions and only have RJMP / RCALL, so they can't address 
a large flash in a natural way.

One thing we could do is setup our own benchmark suite (not the 
testsuite) that could be used to test size / speed regressions in all 
architectures. This could also trigger failures if gcc started using 
invalid instructions for a particular architecture.

We could then have a nice matrix with compiler version / optimization 
setting / architecture, to show regressions on every architecture we 
support.

> Thanks for the good work!

You're welcome :)

--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"Anything is possible, unless it's not."