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

[Björn Haase]

Jörg Wunsch wrote
> p.s.: Björn, the formatting of your message is what I'd call ``close
> to be unreadable''.
... you're  right ``close to unreadable'' is not *really* exagerated,
Sorry for that. I hope the problem is fixed now ...

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

I agree. Seperate libraries for the different instruction sets are a good
idea as long as no dependencies on other things show up only.

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

I think that this would be the cleanest solution.

>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.)

I agree. Comparing avr-libc with other packages (e.g. gdb) build time
in my opinion is not at all important.

The only thing that I think about what might become a little bit more
time consuming is setting up the build environment for the maintainers of
the library.

The only alternative that I see in order to fix the problem is to try to use
the
one device-specific library file that is existing today (i.e. crt-file) to
collect all
the device-specific information. This should be feasible as long as the only
thing to change from device to device could be expressed by a change of
symbols.
E.g. the address of the peripheral registers.

As soon as more than the address of the peripheral devices change one would
run into problems if you whish to maintain the same user interface.


E. Weddington wrote

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

Probably it would be necessary to change the other tools as well. The
mechanism that today
tells the linker to incorporate the device-specific crt-file (don't know how
it works so far)
would need to be adapted as well.

Concluding ... if you plan to plan a major reaarangement and would like to
have
a helping hand: write a mail.

Until then, I will probably best write a hack of the type "quick and dirty"
for my personal use,
since rearranging the whole build system is probably a task for several
months rather than
for several hours. If you think it's useful, I can post it as a
"works_only_on_atmega169_quick_and_dirty_patch" as soon as the savannah cvs
server is functional
again.


Beibei,

 Björn


P.S.:

BTW.: When I was starting to write this mail, I was trying to convince you
of incorporating
equate symbols for the peripheral addresses in the "crt.o"s that should be
resolved at link
time -- only for finding out during writing that this probably would be not
a good idea :-).