Unterschiede im Hex-file (AVR)

[Gerhard (Gast)]

Komische Sache....
Eigentlich habe ich nur ein bisschen Kosmetik betrieben (besser 
formatiert, Variablen umbenannt, ein paar Kommentare hinzugefügt). 
Eigentlich nichts, was den erzeugten code beeinflussen könnte. Kein 
Compilerupdate zwischendurch, gleiche Compilereinstellungen.

Spasseshalber habe ich das mal mit dem alten Hex-file/programmierten 
Chip verglichen und bekomme ne Fehlermeldung.
Alt: Hex-File in AVR-Studio geladen/Disassembler
Neu: listing der aktuellen Variante. Ich seh an Adresse 0x00b8 keinen 
Unterschied. Und die angemeckerten Werte 0x8b bzw 0x8e kann ich da auch 
nicht sehen.

[Stefan E. (sternst)]

Gerhard schrieb:
> Eigentlich habe ich nur ein bisschen Kosmetik betrieben (besser
> formatiert, Variablen umbenannt, ein paar Kommentare hinzugefügt).
> Eigentlich nichts, was den erzeugten code beeinflussen könnte.

Doch. Das Umbenennen von Variablen kann dazu führen, dass der Linker sie 
in einer anderen Reihenfolge anordnet, womit sich dann auch der Code 
ändert.

Gerhard schrieb:
> Ich seh an Adresse 0x00b8 keinen
> Unterschied. Und die angemeckerten Werte 0x8b bzw 0x8e kann ich da auch
> nicht sehen.

Ich würde mal vermuten, dass ein Hex-Compare auf Byte-Basis arbeitet. 
Die Adressen im Hex-Dump sind aber Word-Adressen. Du hast also 
vermutlich an der falschen Stelle geschaut.

[Marc V. (Firma: Vescomp) (logarithmus)]

Gerhard schrieb:
> Eigentlich nichts, was den erzeugten code beeinflussen könnte. Kein
> Compilerupdate zwischendurch, gleiche Compilereinstellungen.

 Ahem.
 Vergleiche mal die Adresse 0x00B7.
 Da ist schon mal mehr Code dazwischen.

[D. F. (Firma: EDF) (derdan)]

Du könntest auch mit deiner Versionverwaltung den code solange Richtung 
Ursprung revertieren bis eindeutig ist, durch welche Änderung sich dein 
Hex File beinflustt hat.

Den Vergleich könntest du ja durch direktes Verglichen des vorher - 
nacher Hexfiles durchführen

[Gerhard (Gast)]

Stefan E. schrieb:
> Ich würde mal vermuten, dass ein Hex-Compare auf Byte-Basis arbeitet.
> Die Adressen im Hex-Dump sind aber Word-Adressen. Du hast also
> vermutlich an der falschen Stelle geschaut.

Ja, supi :-). Die erste Unterschied ist bei 0x005C (rjmp _main).

Und im nachhinein auch den tatsächlichen Unterschied gefunden. Eine 
unbenutzte Variable hatte ich beim Aufräumen rausgeschmissen. Ich dachte 
eigentlich, dass macht der Compiler/linker alleine?

Tut er aber nicht, wenn die auch initialisiert wird.
uint8_t hysterese;   //fliegt rückstandslos raus
uint8_t hysterese=0;  //bleibt im Code, auch wenn hysterese nicht 
referenziert wird.

[Amateur (Gast)]

Einfach Bytes verändern ist nicht.

Du musst die geänderte Zeile neu aufbauen. Wichtig, in diesem 
Zusammenhang, ist die Prüfsumme am Ende JEDER Zeile;)

[Johann L. (gjlayde)]

Gerhard schrieb:
> uint8_t hysterese=0;  //bleibt im Code, auch wenn hysterese nicht
> referenziert wird.

Ist doch ok :-)

Nichts schreibt vor, dass nicht-verwendete Variablen ebtfernt werden 
müssen... avr-gcc macht das zwar, aber offenbar werden andere Tool 
verwendet.

[Jim M. (turboj)]

Gerhard schrieb:
> Und im nachhinein auch den tatsächlichen Unterschied gefunden. Eine
> unbenutzte Variable hatte ich beim Aufräumen rausgeschmissen. Ich dachte
> eigentlich, dass macht der Compiler/linker alleine?

Macht der Linker nur mit --gc-sections. Und das benötigt dann 
-fdata-sections beim Compiler für Daten und -ffunction-sections für 
Funktionen.

[Johann L. (gjlayde)]

Jim M. schrieb:
> Macht der Linker nur mit --gc-sections. Und das benötigt dann
> -fdata-sections beim Compiler für Daten und -ffunction-sections für
> Funktionen.

Nur wenn GNU-Tools verwendet werden, was offensichtlich nicht der Fall 
ist.