Re: [avr-libc-dev] Bug in EEPROM handling routines of avr-libc .?

[E. Weddington]

On 22 Jan 2004 at 21:44, Joerg Wunsch wrote:

> As E. Weddington wrote:
> 
> > >    Today I h
> > > ve tried in vain to use the library functions of avr-libc
> > >    for reading 
> > > nd writing the EEPROM of a atmega169 device.
> 
> > Yes, that is a bug.
> 
> Not really.  As it is now, it has simply been stated in the
> documentation that the EEPROM library is not applicable to the
> ATmega169.  This is a feature, though arguably not a very nice
> one.

Ok, ok, technically it's not a bug. It's more of a "misfeature":
<http://www.catb.org/~esr/jargon/html/M/misfeature.html>
:-)

 
> Given the current library model that only uses different library
> object files for the four major `architectures' (avr2 through avr5),
> there's no chance to have a specially compiled library for just the
> ATmega169.  If we want to resolve this issue (aren't there further
> devices with different register locations, like maybe the USB AVRs?),
> we'd better completely give up the `architecture' model, and create
> one .a file for each supported controller.  After all, the files
> aren't that large at all, and the major part of the build time is
> already required to build the docs, not the actual library.  (A change
> like this one would also be a good occasion to eliminate the separate
> libm.a, and integrate all their functions into libc.a.)

Yes, that's certainly more flexible. Though it's a pretty major refactoring. 
How would this affect binutils and linker scripts?