Gast
#4225837
Wie sieht es mit neueren Compilerversionen aus? Mittlerweise gibt es avr-gcc 5.2. Hat den schon jemand für Windows gebaut? Früher gab's ja regelmäßig mal Binaries.
|
Anzeige
|
avr-gcc 5.2 für Windows
Gast
#4225837
Wie sieht es mit neueren Compilerversionen aus? Mittlerweise gibt es avr-gcc 5.2. Hat den schon jemand für Windows gebaut? Früher gab's ja regelmäßig mal Binaries. Ein Buils ist da: http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ * avr-gcc@gcc-5-branch/HEAD * Binutils@master * AVR-LibC@trunk Komplett ungetestet
Gast
#4243203
Danke. Also ein sehr einfaches Projekt kompiliert. Ein Größeres nicht. Muss noch gucken, warum. Ich wäre vorsichtig. Wir hatten mit verschiedenen Versionen (alle nicht "offizielle" mit dem Studio mitgelieferte) seltsame Probleme. Ich kriege es nicht mehr auf die Reihe, aber ein Kollege hat eine Woche debuggt, bis er dann wieder auf den 4.7.x zurückgegangen ist... Dominik S. schrieb: > ein Kollege hat eine Woche debuggt, Den Compiler oder die Applikation? > Wir hatten mit verschiedenen Versionen (alle nicht "offizielle" mit > dem Studio mitgelieferte) seltsame Probleme. Konkret? Ihr werden wohl nicht bis ultimo auf 4.7.2 bleiben wollen, genauso wie die meisten heute nicht mehr 3.4.6 einsetzen, obwohl die eine der besten war :-) Ok, habe mal ein kleines Projekt (cd. 4k .text) damit durchgenudelt und gleich 2 Fehler gefunden — im Projekt, nicht im Compiler wohlgemerkt! Bug #1 Eine Variable, auf die in einer ISR nur lesend zugegriffen wird, war nicht volatile. Der Code war in etwa so:
Bug #2 Ein Modul verwaltet die Konfiguration der Anwendung und non-volatile Einstellungen im EEprom. Damit andere Module nicht versehentlich die Konfiguration schreiben, war die entsprechende struct-Komponente const. Der Code wurde unter der Annahme geschrieben, dass der Compiler (damals avr-gcc 3.4.6) nicht in anderen Module sieht, so dass keine Undefined Behavior auftritt. Mit GCC 5.2 gibt's dafür nen Tritt in den A.... :-)
Gast
#4246049
Ok, ich habe das Problem gefunden, das bei mir den Compiler crashen lies: Das größere Projekt habe ich immer mit -fipa-pta kompiliert, weil das einiges an Platzersparnis brachte. avr-gcc 5.2 hat da wohl einen Bug. Ohne den Schalter läuft's. Hast du einen Testfall? Vermutlich verletzt dein Code sie Aliasing-Regeln von C.
Gast
#4246809
Das wird ein paar Tage dauern. Aber wenn du mir ein Beispiel gibst, was du damit meinst, kann ich mal nachschauen und den Code kommende Woche vereinfachen und das Problem zu isolieren versuchen. Ein "Testfall" in diesem Zusammenhang ist etwas, das es anderen ermöglicht, einen Fehler nachzuvollziehen. Dies beinhaltet insbesondere: 1) Die Compilerausgabe, wenn die betroffenen s-Dateien zusätzlich mit -v erzeugt werden (ohne LTO ist das nur eine). 2) Die präprozessierten Quellen, d.h. i-Datei (C) bzw. ii-Datei (C++) wie mit -save-temps erzeugt (ohne LTO ist das nur eine Datei). Dies stellt sicher, dass das Modul übersetzt werden kann (keine fehlenden Dateien wie Header, etc.) und keine Makros, Deklarationen, etc. geraten werden müssen. Zudem sieht man OS, Configure- und Compiler-Optionen, Build-Datum und -Version, Vendor, etc. Weil der erzeugte Code nicht ausführbar ist (GCC erzeugt Assembler-Code, also Text), ist eine genaue Fehlerbeschreibung notwendig, evtl. hilf auch die erzeugte s-Datei um den Fehler zu erklären. Ausführbarer Code ist in den nicht hilfreich, da die erforderliche Hardware nicht vorliegt. Bevor man an einen Fehler in der C-Implementation denkt, sollte man einen Fehler in der Applikation in Betracht ziehen: -- Warnungen aktivieren, evtl. auch solche, die nicht in -Wall, -W, oder -Wextra enthalten sind, z.B. -Woverflow, -Wconversion, -Wsign-conversion, -Wstrict-prototypes, -Wmissing-prototyes, -Waddr-space-convert, -Wstrict-aliasing=, -Wstrict-overflow=, ... In deinem Fall z.B. Warnungen, die sich auf Aliasing beziehen. -- Code mit Lint etc. untersuchen, auf Undefined Behavior testen (Signed-Overflow, Aliasing-Regeln, Division durch 0, INT_MIN / -1, Schreiben von nicht-volatile const-Objekten, etc.) Beachte, dass nicht alle Fehler zur Compilezeit erkannt werden können, und Sanitizer für avr-gcc nicht zur Verfügung stehen (wären eh Overkill). In deinem Fall liegt die Vermutung nahe, dass Aliasing-Regeln verletzt werden. Typisches Idiom ist z.B.
oder ähnliche Hacks die Type-Punning über Unions erledigen. Versuchsweise kann mit -fno-strict-aliasing übersetzt werden, ditto -fwrapv oder einzelne Module mit bestimmten Optimierungen deaktiviert oder von LTO ausgenommen, z.B. im Makefile per
Gast
#4247306
Fehler tritt nur auf, wenn -flto und -fipa-pta zusammentreffen. -fno-strict-aliasing und/oder -fwrapv führen zu keiner Besserung. Lint etc. lief schon drüber und -Wextra ist immer an. Spezielle aliasing-Warnungen muss ich noch suchen welche ich am besten einschalte. Mehr kommende Woche wegen Zeitmangels.
Gast
#4247320
Ich persönlich tippe ja auf einen Compilerfehler. avr-gcc haut hier
traditionell viele unsinnige Fehlermeldungen raus.
Ich verwendete bisher die 4.8.1 und da nervte er mich z.B. immer mit
adc.c:16:1: warning: '_vector_21' appears to be a misspelled signal
handler [enabled by default]
ISR(ADC_vect) {
^
Die Software funktioniert aber einwandfrei! Den Umstieg mache ich
hauptsächlich wegen sowas, weil das in mir schon Zweifel und Misstrauen
weckt, ob da nicht doch Bugs im Compiler sind.
+1 für mein Fegefeuer :-) https://gcc.gnu.org/PR59396
Gast
#4247473
Zumindest GCC 4.9.2 gibts als Beta auch von Atmel: http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.5.0-beta/
Gast
#4254058
Es ist gar nicht so einfach, den Bug zu isolieren, da er mal da ist und mal weg. Vor allem hängt er davon ab, wie man die Dateien nennt... Benennt man sie um, kompiliert es!? Ich vereinfache das Projekt noch... Heiner schrieb: > Es ist gar nicht so einfach, den Bug zu isolieren, da er mal da ist und > mal weg. Vor allem hängt er davon ab, wie man die Dateien nennt... > Benennt man sie um, kompiliert es!? Hä? Ich dachte es geht darum, dass dein Code nicht funktioniert, und nicht darum, dass der Build-Vorgang abbricht?
Gast
#4254400
Heiner schrieb: > Also ein sehr einfaches Projekt kompiliert. Ein Größeres nicht. So schrieb ich das. Der Compiler crasht bzw. meldet einen kryptischen Fehler. "section x is missing". Der Fehler tritt bei Verwendung von -flto und -fipa-pta in Abhängigkeit des Dateinamens einer c-Datei und je nach Größe des Codes auf. Ich habe beim Reduzieren meines Projektes gemerkt, dass der Fehler irgendwann weg war. Als ich irgendwelche Nonsense-Operationen einbaute, war er wieder da. Irgendwie läuft da im Compiler was über, glaube ich. Ich hänge das reduzierte Projekt nachher mal an. Heiner schrieb: > Heiner schrieb: >> Also ein sehr einfaches Projekt kompiliert. Ein Größeres nicht. > > So schrieb ich das. Der Compiler crasht bzw. meldet einen kryptischen > Fehler. "section x is missing". Der Fehler tritt bei Verwendung von > -flto und -fipa-pta in Abhängigkeit des Dateinamens einer c-Datei und je > nach Größe des Codes auf. Ich habe beim Reduzieren meines Projektes > gemerkt, dass der Fehler irgendwann weg war. Ah wenn das so ist kannst du doch ganz einfach nen Testfall zur Verfügung stellen, nämlich den / die präprozessierten i-Files, die Optionen (nebst -v) und Console-Ausgabe des Compilers. Wie ist die Ausgabe mit -v ?
Gast
#4254556
Hier kannste dein Glück mal versuchen. make.bat ruft das exakt so auf, wie bei mir. Aber Achtung: Bei der kleinsten Änderung funktioniert es möglicherweise... Bitte noch die Ausgabe des Compilers mit -v. Ich versucht nicht mein Glück, ich versuche dir zu helfen. Dafür brauche ich bestimmte Informationen. Wenn das Thema für dich nicht von Interesse ist, dann sag das bitte.
Gast
#4255353
Hier die Ausgabe mit -v. Mh, ich denke, dass es auch im Interesse anderer Nutzer ist und auch im Interesse der Compilerbauer sein müsste, wenn Fehler in ihrem Produkt korrigiert werden. Oder zumindest besser auf eine Fehlbedienung hinzuweisen, sofern diese vorliegt.
Heiner schrieb: > ich denke, dass es auch im Interesse [...] der Compilerbauer > sein müsste, wenn Fehler in ihrem Produkt korrigiert werden. Ja, ist es. Aber Raten hat sich hier als untauglich erwiesen, und die Information ist mit -v -save-temps einfach und schnell zu erhalten. > Oder zumindest besser auf eine Fehlbedienung hinzuweisen, > sofern diese vorliegt. Sieht mir nicht danach aus. https://gcc.gnu.org/PR67428
Gast
#4255697
Danke. Und jetzt benenne "Bug.c" mal um in "Mug.c" und versuche es erneut. Das ist der Effekt, den ich nicht kapiere. Seh ich keinen Unterschied, weder für x86-linux-gnu noch für avr-unknown-none. Hab allerdings momentan x86-linux-gnu.
Gast
#4255709
Dann ist es Windows-spezifisch. ... und außerdem hab ich alle Header entsorgt, damit ander was mit den Quellen anfangen können :-) einer schrieb: > Dann ist es Windows-spezifisch. Nicht unbedingt, kann auch ein Problem mit der Speicherverwaltung sein. Wir werden sehen, ist ja auf x86 reproduzierbar — und der Traum aller Compileranwender, der Fehler möge im Compiler sein und nicht im eigenen Code ;-) Johann L. schrieb: > https://gcc.gnu.org/PR67428 Ist seit vorgestern behoben, d.h ab GCC 5.3: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66705#c7
Gast
#4260116
Jetzt fehlt nur noch der Download-Link. ;) Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|