[Top][All Lists]

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

Re: [avr-gcc-list] Problems with avrtest simulatorand avr-gcc testsuite.

From: Paulo Marques
Subject: Re: [avr-gcc-list] Problems with avrtest simulatorand avr-gcc testsuite.
Date: Wed, 20 Apr 2011 14:35:02 +0100
User-agent: Thunderbird (X11/20090817)

Georg-Johann Lay wrote:
> Paulo Marques schrieb:
>> Georg-Johann Lay wrote:
>>> Paulo Marques schrieb:
>>>> +/* avrtest counter wrappers */
>>>> +
>>>> +static void start_perf_counter(int number)
>>>> ...
>>>> +static void stop_perf_counter(int number)
>>>> ...
>>> static??
>> Yes, the "exit.c" code is supposed to be included directly into the code
>> that uses it, so that all these small functions get inlined.
>> IIRC this is called "exit.c" and not "avrtest_helpers.h" because of the
>> way the testsuite works...
> The .exp I found for avrtest+atmega just mentions exit.c in ldflags.
> IMO including exit.c won't work because this file is not prepared for
> including. Besides that test programs should not depend on the
> particular implementation of exit/abort, i.e. these functions should
> always be CALLed and not inlined/macro expanded.

I stand corrected. I'm the one who includes the file for a quick test on
a program that is intended for a real avr and I just want to test it on
the simulator for some reason.

> exit.c gets compiled on-the-fly, so together with -O0 and the "naked"
> for abort resp. exit gives odd code because they rely on frame pointer.
> The right way would be to use an exit-amtega128.o that was compiled
> with, say, -Os and make abort/exit "noreturn" instead of "naked".
> Thus, I now use a slightly different setup:
> * avrtest: Disable getchar when reading from STDIO_PORT
> * atmega128-sim.exp: use exit-atmega128.o instead of exit.c directly
> * Reduce namespace pollution in exit.c, build exit-*.o, see attached

I like those changes. exit.c looks cleaner and the Makefile looks a lot

Eric, Georg-Johann seems to be motivated to improve avrtest and run the
testsuite. Maybe he should be given sourceforge access to commit the
improvements directly? Georg, do you have a sourceforge account?

As for the performance counters, maybe it would be even better to just
create a "perfcounter.h" include file that defines the perf counters as
macros, i.e., something like:


#define START_PERF_PORT 0x53
#define STOP_PERF_PORT  0x54

#define start_perf_counter(a)  (*((volatile unsigned char *)

#define stop_perf_counter(a)   (*((volatile unsigned char *)


These aren't used for the testsuite, so they shouldn't affect the
testsuite setup at all. To test a regular program, the user just needs
to include this file. If everyone agrees, I'll just commit this version

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

"This version has many new and good features. Sadly, the good ones are
not new and the new ones are not good."

reply via email to

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