WinAVR+Eclipse->region text is full

[Heiko (Gast)]

Hallo!
Ich bekomme unter Eclipse die Meldung "region text is full", wenn ich 
das PN aus WinAVR nehme gehts aber...

[Jörg W. (dl8dtl) (Moderator)]

-mmcu= fehlt beim Linken.  Ich dachte, diesen Bug hätte da endlich
mal jemand repariert?

[Heiko (Gast)]

-mmcu ist da.

Ich poste mal wie unterschiedlich die einzelnen .c-Files kompiliert und 
gelinkt werden.

Kompilerausgabe aus "PN"+"MFile"+"WinAVR":

Compiling C: y1.c
avr-gcc -c -mmcu=atmega88 -I. -gstabs -DF_CPU=16000000UL -Os -Wall -Wstrict-prototypes -Wundef -Wunreachable-code -Wsign-compare -Wa,-adhlns=obj/y1.lst  -std=gnu99 -Wundef -MD -MP -MF .dep/y1.o.d y1.c -o obj/y1.o

Kompilerausgabe aus "Eclipse3.3"+"CDT4"+"avr-eclipse"+"WinAVR":

Building file: ../y1.c
Invoking: Compiler
avr-gcc -Wall -g -O2 -Os -c -mmcu=atmega88 -DF_CPU=16000000 -o"y1.obj" "../y1.c"
Finished building: ../y1.c

Linkerausgabe aus "PN"+"MFile"+"WinAVR":

Linking: x.elf
avr-gcc -mmcu=atmega88 -I. -gstabs -DF_CPU=16000000UL -Os -Wall -Wstrict-prototypes -Wundef -Wunreachable-code -Wsign-compare -Wa,-adhlns=obj/y1.o  -std=gnu99 -Wundef -MD -MP -MF .dep/x.elf.d obj/y1.o obj/y2.o obj/y3.o obj/y4.o obj/y5.o obj/y6.o obj/y7.o obj/y8.o obj/y9.o obj/y10.o obj/y11.o obj/y12.o obj/y13.o obj/y14.o obj/y15.o --output x.elf -Wl,-Map=x.map,--cref    -lm

Linkerausgabe aus "Eclipse3.3"+"CDT4"+"avr-eclipse"+"WinAVR":

Invoking: Linker
avr-gcc -Wl,-Map,.map -mmcu=atmega88 -o"x.elf"  ./y1.obj ./y2.obj ./y3.obj ./y4.obj ./y5.obj ./y6.obj ./y7.obj ./y8.obj ./y9.obj ./y10.obj ./y11.obj ./y12.obj ./y13.obj ./y14.obj ./y15.obj   
c:\WinAVR\bin\..\lib\gcc\avr\3.4.6\..\..\..\..\avr\bin\ld.exe: region text is full (x.elf section .text)

Nein, ich nenne meine einzelnen Files nicht x und y- meine Namen sind 
noch bekloppter und deshalb nicht vorzeigbar ;)

[kosmonaut_pirx (Gast)]

hallo,
hat vielleicht gar nicts damit zu tun, aber:

>avr-gcc -Wall -g -O2 -Os -c -mmcu=atmega88 -DF_CPU=16000000 -o"y1.obj" "../y1.c"

was bewirkt die zweimalige angabe der optimierung .. grübel
bye kosmo

[Heiko (Gast)]

Ja, über die bin ich auch gestolpert, aber das kann ich in Eclipse nicht 
verhindern, da ist -Os eine checkbox, also zuschaltbar zu den "normalen" 
Optimierungseinstellungen.

[Heiko (Gast)]

Gerade nochmal nachgeschaut:

"If you use multiple ‘-O’ options, with or without level numbers, the 
last such option is the one that is effective."

Also sollte das -Os von Eclipse das -O2 "überstimmen", weil es an 
letzter Stelle steht.

[Jörg W. (dl8dtl) (Moderator)]

Was mir noch auffällt ist, dass dein Eclipse kein -lm linkt.

[Heiko (Gast)]

Bingo.

Das war es.

Warum wird der Code beim Hinzufügen der libm.a kleiner?

[Jörg W. (dl8dtl) (Moderator)]

> Warum wird der Code beim Hinzufügen der libm.a kleiner?

Weil (leider) die libgcc.a manchen Code doppelt, der stattdessen
handoptimiert in der libm.a abgelegt worden ist.  Historischer
Ballast.  Der handoptimierte Code sollte besser in die libgcc.a
kommen, aber das war historisch rein als Folge der GCC-Lizenzpolitik
(du musst der FSF dein Copyright abtreten -- auch wenn das nach
deutschem Recht, glaub' ich, null und nichtig ist :) praktisch nicht
möglich.

Mit der von Дмитрий Хмельков (Dmitry Xmelkov) neu geschriebenen
libm, die in avr-libc ab Version 1.6 vorhanden sein wird, sehe ich
aber gute Chancen, dass man diesen historischen Fehler reparieren
kann.

[Heiko (Gast)]

Na, zum Glück werden dann ja "von Hand gelinkte" libraries bevorzugt.

Das -lm hätten die "avr-eclipse" Leute ja dann eigentlich auch als 
Standard setzen können.

Ok, ich bedanke mich für die tolle Hilfe hier- da kommt man doch gerne 
öfters mal vorbei ;)!

[Jörg W. (dl8dtl) (Moderator)]

Heiko wrote:

> Das -lm hätten die "avr-eclipse" Leute ja dann eigentlich auch als
> Standard setzen können.

Ja, sag ihnen das mal.  Das ist auf jeden Fall sinnvoll.

[Klaus F. (kfalser)]

> Weil (leider) die libgcc.a manchen Code doppelt, der stattdessen
> handoptimiert in der libm.a abgelegt worden ist.

Wo findet man diese Geheimnisse dokumentiert?

[Jörg W. (dl8dtl) (Moderator)]

> Wo findet man diese Geheimnisse dokumentiert?

``All documentation files usually end up in ".c".''

(Unbekannter Autor)

[Klaus F. (kfalser)]

oder "asm" ?