Hallo,
ja, ich weiß, wenn man glaubt der Compiler macht einen Fehler, dann war
man das meistens selber.
Aber ich hab mir den Disassembler angeschaut, und mit verschiedenen
Werten experimentiert, und alles deutet darauf hin dass es wirklich der
Compiler war.
Frage an euch: Bin ich blöd, oder der Compiler? Ist der Fehler schon
bekannt (Nach welchen Suchbegriffen würdet ihr suchen?), oder sollte ich
versuchen ein minimales Programm zu bauen, das den Fehler reproduziert?
Die Compilerversion:
1
avr-gcc --version
2
avr-gcc (AVR_8_bit_GNU_Toolchain_3.3.0_364) 4.5.1
3
Copyright (C) 2010 Free Software Foundation, Inc.
4
This is free software; see the source for copying conditions. There is NO
5
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Mit diesen Optionen (Dateinamen und Includepfade rausgekürzt)
Zuordnung zwischen Parametern und Registern, wie angezeigt von AVR
Studio 4.19 bei Mouseover:
v0 = R24:R25
v1 = R23:R22
v2 = R21:R20
v3 = R19:R18
Der Disassembler, mit Anmerkungen von mir (bitte korrigiert mich wenn
ich was falsch verstanden habe. Ich programmiere AVRs eigentlich nicht
in Assembler)
siehe
http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_nomenclature.html
X=R27:R26, Y=R29:R28 and Z=R31:R30
X scheint auf input zu zeigen.
Mal abgesehen davon dass ich nicht verstehe, dass avr-gcc da OR Befehle
braucht wenn ich eigentlich nur Low- und High-Byte zusammenbauen wollte,
und die dauernde Hin- und Herschieberei der X Register kommt mir auch
unnötig vor...
Soweit ich diesen Disassembler verstehe, wird für das High-Byte von
Parameter v3 nicht input[7], sondern input[5] verwendet.
Und genau das beobachte ich auch, wenn ich Test-Werte über TWI
reinschicke:
Eingabe: 258, 269, 0x305, 0x0106
Ergebnis: 258, 269, 773, 774
Ein compilierbares Beispiel wäre nicht schlecht. Der Assemblercode ist
nicht vollständig genug, zumindest kann ich nicht erkennen, was im
Y-Register steht.
Oliver
Ich habe jetzt ein kleines AVR-Studio Projekt (bug.zip) gemacht, mit dem
sich der Fehler reproduzieren lässt. Breakpoint aufs return von main,
dort hat die Variable parameter_in_function den falschen Wert.
Der falsch compilierte Teil ist in einer ganz kurze Datei, bug.c:
Abgesehen von dem vermuteten Fehler, würde ich empfehlen dieser Funktion
einfach das Array zu übergeben anstatt 4 Paramter mit Shift-Operationen
beim Aufruf! Oder zumindest das Tauschen der Bytes mit localen variablen
erledigen.
Läuft der Code denn ohne oder mit anderen Optimierungsstufen?
Johann L. schrieb:> Denkbar ist https://gcc.gnu.org/PR46779
Aus dem Ticket:
It seems to be that the generation of the code goes wrong if using size
optimization, inline assembler and nested loops.
Selbst wenn es der gleiche Fehler ist, dann hab ich ihn unter anderen
Vorraussetzungen bekommen. Size Optimization JA, inline assembler und
nested loops NEIN.
Allerdings: https://gcc.gnu.org/PR45291 und noch ein paar andere
sind als Duplikat verlinkt, und kommen auch ohne inline assembler und
nested loops aus.
m. keller schrieb:> Abgesehen von dem vermuteten Fehler, würde ich empfehlen dieser Funktion> einfach das Array zu übergeben
Geht nicht so einfach, ist generierter Code für dem Empfang von TWI
Nachrichten.
> Läuft der Code denn ohne oder mit anderen Optimierungsstufen?
Hab ich noch nicht probiert.
Ist das sinnvoll, oder sollte ich lieber gleich eine andere
Compilerversion nehmen?
Sebastian schrieb:> Johann L. schrieb:>> Denkbar ist https://gcc.gnu.org/PR46779>> Nächster Schritt wird wohl sein, das Beispiel im GCC Bug Tracker zu> melden, um zu sehen ob es der ist, oder?
Die 4.5 wird nicht mehr supportet, die älteste supportete Version ist
4.9.
Außerdem verwendest du die 4.5.1 obwohl die 4.5.4 diesen Bug behoben
hat.
Sebastian schrieb:> Johann L. schrieb:>> Denkbar ist https://gcc.gnu.org/PR46779>> Aus dem Ticket:> It seems to be that the generation of the code goes wrong if using size> optimization, inline assembler and nested loops.>> Selbst wenn es der gleiche Fehler ist, dann hab ich ihn unter anderen> Vorraussetzungen bekommen. Size Optimization JA, inline assembler und> nested loops NEIN.
Die Leute schreiben alle möglichen Theorien und Spekulationen in ihre
Bug-Reprorts. Fakt ist, dass PR46779 weder was mit Inline Asm noch mit
Loops zu tun hat.
> Allerdings: https://gcc.gnu.org/PR45291 und noch ein paar andere> sind als Duplikat verlinkt, und kommen auch ohne inline assembler und> nested loops aus.
QED
Johann L. schrieb:> Die 4.5 wird nicht mehr supportet, die älteste supportete Version ist> 4.9.
D.h. einen Bug-Report, den man mit 4.9 nicht reproduzieren kann, wird
niemand beachten, kann ich mir also sparen?
> Außerdem verwendest du die 4.5.1 obwohl die 4.5.4 diesen Bug behoben> hat.
Du meinst also, es handelt sich wirklich um PR46779, ich brauche mir
also mit allem >= 4.5.4 keine Sorgen zu machen?
Zur Erklärung, warum ich diese Version verwende: Das war halt die, die
man bei Atmel runterladen konnte, als ich mit den AVR angefangen habe,
und die noch anstandslos mit AVRStudio 4.19 funktioniert. (Inzwischen
hat sich ja rausgestellt, dass auch die neuen mit den entsprechenden
Parametern gehen, das wusste ich damals aber noch nicht:
Beitrag "Avr Studio 4 und die neue AVR Toolchain - So funktionierts!")
Was für eine Version würdet ihr denn inzwischen empfehlen? Eine von
Atmel gepatchte, oder eine (z.B. 4.9.3?) aus dem normalen gcc
repository?
Mir kommts nicht so sehr auf neue features an. Hauptsache es tut.
Und mit dem AVRStudio 4.19 war ich bisher auch ganz zufrieden (läuft
auch auf einem Uralt-Laptop noch, den ich ab und zu zum debuggen nehme,
weils mir den Transport eines anderen Computers spart).
sebastian schrieb:> Johann L. schrieb:>> Die 4.5 wird nicht mehr supportet, die älteste supportete Version ist>> 4.9.> D.h. einen Bug-Report, den man mit 4.9 nicht reproduzieren kann, wird> niemand beachten, kann ich mir also sparen?
Ja.
Außerdem gibt's in ein paar Wochen die v6, dann wird die älteste noch
Support genießende Version die v5 werden.
>> Außerdem verwendest du die 4.5.1 obwohl die 4.5.4 diesen Bug behoben>> hat.> Du meinst also, es handelt sich wirklich um PR46779, ich brauche mir> also mit allem >= 4.5.4 keine Sorgen zu machen?
Den Bug konnte ich mit der 4.5.0 nachvollziehen. Und ja, es passt auf
PR46779. Ich wüsste keinen anderen Bug der ähnliche Artefakte erzeugt.
> Was für eine Version würdet ihr denn inzwischen empfehlen? Eine von> Atmel gepatchte, oder eine (z.B. 4.9.3?) aus dem normalen gcc> repository?
Generell: Wenn du dich für eine Release entschieden hast, dann willst du
immer die neueste Bugfix-Release. Bei v4 ist das also 4.y.x mit dem
größten x, das du bekommen kannst. Sinngemäß bei v5 aufwärts die v5.x
mit dem größten x (ab v5 hat sich die Versionszählung geändert).
> Mir kommts nicht so sehr auf neue features an. Hauptsache es tut.> Und mit dem AVRStudio 4.19 war ich bisher auch ganz zufrieden (läuft> auch auf einem Uralt-Laptop noch, den ich ab und zu zum debuggen nehme,> weils mir den Transport eines anderen Computers spart).
Die Atmel-Releases kümmern sich vor allem um Device-Support.
Die 4.7.3+ hatte auf mich nen ganz guten Eindruck gemacht, und die v5
ist auch okay, wobei die 5.2 mit -flto -fipa-pta falschen Code erzeugen
kann (fix in 5.3). v5.x mit x < 2 funktioniert hingegen nicht. Und
gegen 4.9.3 ist auch nix zu sagen.
Thread beobachten
Seitenaufteilung abschalten