[avr-libc-dev] Re: Newlib [was: Re: Release?]

[E. Weddington]

Paul Schlie wrote:

> > From: "E. Weddington" <address@hidden>
> >    
> >
> > > Although a little off topic, anyone consider the possibility of contributing
> > > it as the basis of an avr newlib/binutils port/directory of those efforts,
> > > and consolidating effort avr effort there, as opposed to proceeding in
> > > parallel? Or are there legal/logistical issues/complexities of doing so?
> > >
> > > (as just thought it might help raise the effort's visibility?)
> > >      
> > I don't know all the history. Marek knows it though.
> >
> > IIRC, it started originally in newlib. I'm not completely sure of the
> > reason why avr-libc was broken off. But there are some advantages to
> > having a C lib seperate from newlib, in that we can put in AVR specific
> > headers and code, such as the bootloader, etc. I would certainly welcome
> > more comments from others in this area.
> >
> > The avr port of newlib was only recently revived by the RTEMS people as
> > they are going to be using it (newlib) for the RTEMS OS.
> >
> > There might be some advantages into re-integration, such as better
> > support for the math libary. On the other hand, avr-libc could be
> > extended to better support the needs of OSes such as RTEMS. (I've talked
> > to the RTEMS AVR maintainer about this.)
> >
> > But anything along these lines will have to be done in the future after
> > a release.
> >    
>
> Browsing in newlib, it would seem that avr-libc could complement newlib
> (which is basically a C source code library), 
That's not quite correct.
There is GLibC, which is used as the Standard C library for many hosts.
There is Newlib, which is used as the Standard C library for many 
embedded platforms. It is supposed to be smaller, and have better 
licensing for embedded platforms.
There is avr-libc, which is used as the Standard C libarary for the AVR 
platform.

avr-libc and Newlib are not necessarily completementary, as a whole. 
Ideally, one would replace the other. Though avr-libc has functionality 
that is AVR-specific that is not normally found in Newlib.

There would have to be a process of even seeing if Newlib for the AVR is 
efficient enough, and resolving whatever differences there are. This is 
not insignificant.


> And with a little luck, possibly even get the gdb folks to accept simulavr
> as an avr simulator 
Seperate issue.

Something is definitely needed to run the GCC test suite for the AVR. I 
don't know offhand what this would look like.


> (although structured and interfaced differently than the
> others; but don't know if it's a good idea, as the gdb folks seem to have
> recently adopted the notion that gdb is to be focused on linux debugging,
> leaving embedded target support somewhat in a cumbersome position; 
That thread was mostly just a rant; I don't see it really changing anything.

> and
> further complicated as Ted appears to feel a little
> burned-out/overwhelmed/disillusioned at the moment?)
>
>  
A new AVR GDB maintainer will have to be found.

Eric