[Top][All Lists]

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

Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

From: Joel Sherrill
Subject: Re: [avr-libc-dev] Porting RTEMS patches to avr-libc
Date: Mon, 7 Jan 2013 12:38:08 -0600
User-agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20121121 Thunderbird/10.0.11

On 01/07/2013 12:31 PM, Georg-Johann Lay wrote:
Weddington, Eric wrote:
First, I think it's great that you're working on this, and I'm all for
having RTEMS synced with avr-libc, as much as is feasible.

The current release of avr-libc is 1.8.0, though we've been discussing
recently about fixing a bunch of bugs on HEAD for a future 1.8.1 release.
So, I would definitely suggest taking a look at porting 1.8.0, or even
better making sure that it works with HEAD.

Avrtest is what is being used to test with the GCC testsuite. Although I
thought some work was also being done with simulAVR to make it work with the
GCC testsuite (perhaps someone else on this list can confirm or correct me
if I'm wrong).

Additional recommendations: IIRC, there are some specific GCC bugs that are
avr-rtems specific (though less than a handful). Eventually, you, or someone
else on the RTEMS team, may want to take a look at those.
AFAIK, there are no avr-rtems bugs in GCC.  There are PR50925 (ICE: spill fail
in newlib build) and PR52488 (ICE for insanely memory allocation like 2000
bytes for attiny).  These are no genuine RTEMS problems, they just occur
because a different, less common code base (newlib) is compiled.  Similar
problems can just as well occur with non-rtems configuration.

Joel and I have talked off and on over the years, and as I understood it,
RTEMS was using newlib for its C library. Does RTEMS now use avr-libc? Or
just a portion of avr-libc?

If RTEMS will be using avr-libc on a more permanent basis for the future,
then perhaps we'll want to make sure that we coordinate testing, bug fixing,
If RTEMS wants to use avr-libc, extending --with-avrlibc seems warranted so
that is covers avr-rtems, see PR54461.
I thought about this some over the holidays and need to talk to some
of the other core developers when they get back from holiday.

I am thinking that if we start by restricting the subset of RTEMS that
we want on the AVR, then live gets enormously easier when changing
C libraries. The way newlib and RTEMS integrate, you have RTEMS
providing the bottom system calls expected by newlib. newlib owns
some .h files that we provide the implementation of (pthread.h being
at the top of the list). Plus we have our own malloc implementation.

I want to discuss starting with only the subset of RTEMS that is the
"Classic API" with no filesystems or networking. This would bring
a tasking RTOS comparable to ThreadX, VxWorks or Nucleus and
be independent of POSIX. This would simplify the integration with
avr-libc. Then we could discuss which pieces of RTEMS make sense
to enable.


Joel Sherrill, Ph.D.             Director of Research&  Development
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985

reply via email to

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