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

[Georg-Johann Lay]

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,
> etc.

If RTEMS wants to use avr-libc, extending --with-avrlibc seems warranted so
that is covers avr-rtems, see PR54461.


Johann