Ich habe diesmal eine "merkwürdigkeit" beim kompilieren meines projektes mit optimierung in avrstudio bemerkt: Ich habe in meinem projekt eine struktur, die quasi überall im code als globale variable verwendet wird. Wenn ich zu dieser struktur nun elemente hinzufüge, ist gcc offenbar so schlau zu merken, dass diese noch nirgends im code verwendet werden. Füge ich eine verwendung des elementes nun in einer der quelldateien hinzu und habe das projekt zuvor kompiliert, so wird natürlich nur die geänderte quelldatei neu kompiliert und etwaige änderungen der elementadressen werden nicht für die anderen quellcode dateien übernommen. Durch komplettes rebuild des projektes kann man das problem offenbar beheben, jedoch frage ich mich ob ich da über einen fehler gestolpert bin, oder liegt es eventuell sogar an der zusammengestückelten toolchain(neustes winavr und gcc4.7-sp8-di-182625)? Ist es richtig, wenn ich annehme, dass beim build make entscheidet was neu kompiliert werden muss und was nicht? Hier noch die (optimization)flags, die dem compiler übergeben werden: -funsigned-char -funsigned-bitfields -DF_CPU=16000000UL -Os -fno-split-wide-types -fpack-struct -mcall-prologues -fno-tree-loop-optimize -fno-tree-switch-conversion -ffunction-sections -fpack-struct -fshort-enums -Wall -c -gdwarf-2 -std=gnu99 -fdata-sections -mmcu=atmega16 und für den linker: -Wl,-lm -Wl,--gc-sections -Wl,--relax -mmcu=atmega16 ist da vielleicht eine "gefährliche" option enthalten, die das verhalten erklärt? ist vielleicht -fpack-stuct dafür verantwortlich, dass überhaupt member einer struktur wegen nichtverwendung wegoptimiert werden? ich hatte es eigentlich so verstanden, dass dieser schalter nur wichtig ist, wenn man 16 oder 32 bit variablen optimal im speicher ausrichten will, was bei avrs ja egal sein sollte...
Sebastian Steppeler schrieb: > globale variable verwendet wird. Wenn ich zu dieser struktur nun > elemente hinzufüge, ist gcc offenbar so schlau zu merken, dass diese > noch nirgends im code verwendet werden. Sicher nicht. Wenn dein Projekt aus mehreren Dateien besteht hat der Compiler keinen Überblick darüber, was wo verwendet wird. gcc KANN gar nicht 'merken', dass ein Strukturmember nirgends verwendet wird. Und was er auf gar keien Fall machen darf: den Member rauswerfen. > Füge ich eine verwendung des > elementes nun in einer der quelldateien hinzu und habe das projekt zuvor > kompiliert, so wird natürlich nur die geänderte quelldatei neu > kompiliert und etwaige änderungen der elementadressen werden nicht für > die anderen quellcode dateien übernommen. Durch die Verwendung eines Strukturmembers ändert sich keine Adresse. > Ist es richtig, wenn ich annehme, dass beim build make entscheidet was > neu kompiliert werden muss und was nicht? richtig. Aber auch make findet das nicht raus, sondern stützt sich auf ein Makefile in dem Klip und Klar drinnen steht, welche Datei von welcher anderen Datei abhängt. Wenn dieses Makefile nicht korrekt ist, so dass da zb eine Abhängigkeit zu einem Header File fehlt, in dem die Strukturdefinition enthalten ist, dann kommt es zu solchen Effekten. > ist da vielleicht eine "gefährliche" option enthalten, Compiler Optionen habe da erst mal nichts damit zu tun.
Karl Heinz Buchegger schrieb: > Sicher nicht. > Wenn dein Projekt aus mehreren Dateien besteht hat der Compiler keinen > Überblick darüber, was wo verwendet wird. gcc KANN gar nicht 'merken', > dass ein Strukturmember nirgends verwendet wird. Und was er auf gar > keien Fall machen darf: den Member rauswerfen. > Okay dann ist mein weltbild über die toolchain jetzt wieder gerichtet. Habe offenbar etwas voreilig schlüsse gezogen - entschuldigung. Habe mal gerade etwas genauer nachgeforscht und herausgefunden, dass avrstudio bei änderung der struktur in der headerdatei garnichts neu kompiliert. Generiert es dann wohl ein falsches makefile? Ich nutze avrstudio5. Ist das eventuell ein bug im avrstudio, oder habe ich etwas falsch eingestellt?
Sebastian Steppeler schrieb: > Habe mal gerade etwas genauer nachgeforscht und herausgefunden, dass > avrstudio bei änderung der struktur in der headerdatei garnichts neu > kompiliert. Generiert es dann wohl ein falsches makefile? Sieht wohl so aus. Ich benutze allerdings 5 noch nicht und ehrlich gesagt hab ich beim 4-er noch nie darauf geachtet.
Sebastian Steppeler schrieb: > Habe mal gerade etwas genauer nachgeforscht und herausgefunden, dass > avrstudio bei änderung der struktur in der headerdatei garnichts neu > kompiliert. Generiert es dann wohl ein falsches makefile? Ich nutze > avrstudio5. Ist das eventuell ein bug im avrstudio, oder habe ich etwas > falsch eingestellt? In AvrStudio4 gebe ich alle benötigten eigenen Include-Dateien unter "Header Files" an. Wenn ich dann eine der Include-Dateien ändere, wird auch die C-Datei, die dieses Include benutzt, automatisch neu kompiliert. AvrStudio4 erzeugt nämlich ein Makefile, wo diese Abhängigkeit explizit drinsteht. Seit dem Wochenende habe ich das AvrStudio5 installiert. Noch habe ich dort nicht gefunden, wie man dort die eigenen Includes anmeldet, so dass die nötige Abhängigkeit im Makefile durch AvrStudio5 hinterlegt wird... Ich habe daher im Moment dasselbe Problem wie Du ;-) Du magst das AVRS5 "komfortabler" finden (siehe anderen Thread), ich empfinde es einfach nur als riesengroßen unübersichtlichen Klotz ;-) Wenn ich was rausfinde, schreibe ich es hier. Gruß, Frank
naja der hauptgrund warum ich umgestiegen bin war der, dass ich 4 programme habe, die zu dem gleichen bastelprojekt gehören und immer 4 avrstudio4 fenster offen zu halten wurde mit der zeit arg unübersichtlich. Naja und die autovervollständigen funktion kam dann auch wie gerufen, da ich die von früher gewohnt war und es immer doof fand, dass avrs4 das nicht konnte. Ich habe die headerdateien bei avrs5 einfach so in das projekt eingefügt, den headerdateien-ordner gab es ja nicht mehr, aber von neukompilieren will es da trozdem nix wissen. Naja so lange man es weiß kann man damit leben.
Gast
#2592784
Frank M. schrieb: > Noch habe ich > dort nicht gefunden, wie man dort die eigenen Includes anmeldet, so dass > die nötige Abhängigkeit im Makefile durch AvrStudio5 hinterlegt wird... ??? Es funktioniert doch alles so, wie es soll. Oliver
Oliver schrieb: > ??? > > Es funktioniert doch alles so, wie es soll. > > Oliver D.h. bei dir werden alle quellcodedateien neu kompiliert, wenn du in einer headerdatei von der sie abhängen etwas änderst?
Habe ein bisschen weiter rumgetestet und weiß jetzt mehr. es ist aber ein bisschen gruselig: Das korrekte neukompilieren funktioniert unter avrstudio 5.0 nur dann wenn man die eingebaute toolchain oder ein winavr nutzt(habs mit dem neusten probiert). Sobald ich aber gcc4.7.0 verwende kommt er nicht mehr auf die idee etwas neu zu kompilieren, wenn ich ein headerfile ändere. Gibt es eventuell doch einen bug in der toolchain, oder ist mein verwendetes make irgendwie inkompatibel mit dem neusten gcc?
Sebastian Steppeler schrieb: > Das korrekte neukompilieren funktioniert unter avrstudio 5.0 nur dann > wenn man die eingebaute toolchain oder ein winavr nutzt(habs mit dem > neusten probiert). Sobald ich aber gcc4.7.0 verwende kommt er nicht mehr > auf die idee etwas neu zu kompilieren, Jetzt ist mir klar, warum wir dasselbe Problem haben. Natürlich habe ich nach der Installation von AvrStudio5 direkt die gcc 4.7.0 Toolchain scharfgemacht.
Habe das Problem nun durch zufall gelöst, aber verstehe nicht warum, bzw. warum er da keine fehlermeldung für ausgibt: Habe den Pfad des gcc zu der umgebungsvariable "path" hinzugefügt. Nun verhält sich alles so wie es soll und ich habe keine ahnung wieso. EDIT: Ich nehme alles zurück, hatte aus versehen noch winavr eingestellt und nicht gemerkt :(
So ich weiß jetzt was da schiefläuft. Man sieht es in den dependency files in der ersten zeile. der gcc4.7 fügt die objektdatei nicht zu den abhängenden dateien hinzu: gcc4.7 AVRGCC1test.d zeile 1: AVRGCC1test.d: .././AVRGCC1test.c \ gcc4.5.1 AVRGCC1test.d zeile 1: AVRGCC1test.d AVRGCC1test.o: .././AVRGCC1test.c \ ist das jetzt ein bug im avrgcc oder macht avrstudio im makefile eine schweinerei? Ich habe es mal angehängt.
Sebastian Steppeler schrieb: > ist das jetzt ein bug im avrgcc oder macht avrstudio im makefile > eine schweinerei? Drösel es eben auf: Schau dir den Compileraufruf an, den make ausgibt. - Ist der Compileraufruf wie erwartet? - Verhält sich der Compiler mit diesen Optionen wie in der Doku beschrieben?
Gast
#2593591
Oder schlag im RTFM die Compileroptionen zur Erzeugung der dependencies durch, und schau nach, ob die im makefile richtig benutzt werden Du kannst auch im Studio im Dep-Ordner nachsehen, ob deine .h-files dort aufgelistet sind. Oliver
Johann L. schrieb: > > Drösel es eben auf: Schau dir den Compileraufruf an, den make ausgibt. > > - Ist der Compileraufruf wie erwartet? > > - Verhält sich der Compiler mit diesen Optionen wie in der Doku > beschrieben? Der compileraufruf schaut bei mir wie folgt aus: [code]C:/avrgcctc4.7/avr-gcc-4.7-sp8-di-182625-mingw32/bin/avr-gcc.exe" -funsigned-char -funsigned-bitfields -O0 -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -mmcu=atmega16 -MD -MP -MF"AVRGCC1test.d" -MT"AVRGCC1test.d" -o"AVRGCC1test.o" ".././AVRGCC1test.c"[code] Wenn ich im manual nachschlage und das da richtig verstehe dann müsste -MT dafür sorgen, dass das abhängende target im .d file vom standard AVRGCC1test.o abgeändert wird zu .d Demnach würde der gcc4.7 sich dokumentationskonform verhalten. Die älteren compilerversionen verhalten sich offenbar aber anders und ersetzen das target mit -MT nicht, sondern fügen eins hinzu. Zu diesem verhalten finde ich im changelog des gcc leider nichts. Jemand eine Idee?
Dann noch eine dumme frage: Ist es überhaupt sinnvoll AVRGCC1test.d als abhängende datei in sich selbst zu schreiben, so wie avrstudio es offenbar macht? Versteht jemand warum die das machen?
Sebastian Steppeler schrieb: > Demnach würde der gcc4.7 sich dokumentationskonform verhalten. Die > älteren compilerversionen verhalten sich offenbar aber anders und > ersetzen das target mit -MT nicht, sondern fügen eins hinzu. Sowas? http://gcc.gnu.org/PR44076 Aber wie man was sucht weist ja selber... > Zu diesem verhalten finde ich im changelog des gcc leider nichts. > Jemand eine Idee? Im Zweifelsfalle nachfragen in gcc-help@ http://gcc.gnu.org/lists.html Die Macher des GCC sind dort. Nicht hier.
Okay ich hatte ein bisschen probleme mit dem googlen von gcc kommandoparametern aber habe den bug nun gefunden: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448 ist behoben worden und nun sind die avrstudio makefiles nicht mehr kompatibel mit dem aktuellsten gcc. Werde mich mal mit atmel in verbindung setzen...
Sebastian Steppeler schrieb: > nun sind die avrstudio makefiles nicht mehr kompatibel mit dem > aktuellsten gcc. Werde mich mal mit atmel in verbindung setzen... D.h. die verwenden Sachen, die nirgends dokumentiert sind und lediglich wegen eines GCC-Bugs funktioniert haben?
Ganz genau. Vielleicht ist es auch deren workaround um den bug, aber kann ich mir nicht vorstellen...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.