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.