Hallo,
ich versuche gerade einen Parser für ein Projekt zu schreiben,
allerdings habe ich ein Problem mit der Ausgabe von Werten mittels
sprintf.
Mitlerweile konnte ich das Problem auf einen Reset zurückführen.
1
#include"main.h"
2
3
charbuffer[101];
4
5
intmain()
6
{
7
PORTH.DIR=0xFF;// kompletten Port als Output schalten
8
PORTH.OUT=0x55;
9
10
for(;;)
11
{
12
PORTH.OUT=0x00;
13
test();
14
}
15
}
main.h
1
#ifndef __main__
2
#define __main__
3
4
#include<stdlib.h>
5
#include<avr/io.h>
6
#include<stdlib.h>
7
#include<avr/interrupt.h>
8
9
#include<stdio.h>
10
#include<stdint.h>
11
#include"test.h"
12
13
14
externcharbuffer[101];
15
16
#endif
test.h
1
#include<stdlib.h>
2
#include<avr/io.h>
3
#include<stdlib.h>
4
#include<avr/interrupt.h>
5
6
#include<stdio.h>
7
#include<stdint.h>
8
9
10
voidtest(void);
test.c
1
#include"main.h"
2
#include"test.h"
3
4
5
voidtest(void)
6
{
7
sprintf(buffer,"%d, %d",0,6);
8
9
}
Eigentlich besteht das Programm nur aus der Hauptschleife und einer
Unterfunktion in der ich sprintf aufrufe. der Buffer ist dabei als
globale Variable angelegt.
Mit einem Scop kann man sehen, das das System immer wieder neu startet
und auch im Debugger zeigt sich dieses Problem. Der Aufruf von sprintf
verändert den Stack so weit, das das return aus der Funktion test
fehlschlägt.
Meine Kristallkugel sagt: Du verwendest die neueste Version von WinAVR?
Da hat's ein paar Bugs drin. Wenn auch in deinem Programm keine Fehler
generiert werden, so sind doch die Target-Libs damit erstellt (libgcc,
libc, libm, ...). Du linkst also auch gegen potentiell inkorrekte Libs.
Selbst wenn das bei deinem Projekt nicht das Problem ist, sollte man
Ärger durch den Compilerbug versuchen auszuschliessen, indem man einen
funktionierenden Compiler/Libs nimmt.
Johann
OK, ich hab gerade festgestellt, daß es noch eine neure Version als
meine bisher verwendete gibt.
Mit der 20090313 tritt der Fehler in meinem "Demo"Programm zumindestens
nicht mehr auf.
Wobei das irgendwie der Aussage von Johann widerspricht, der ja sagt in
der neuesten Version sind ein paar Fehler drin.
Wie schließe ich die Fehler durch den Compilerbug am besten aus und
welche Version sollte man benutzen?
Mike
Mike S. wrote:
> Wobei das irgendwie der Aussage von Johann widerspricht, der ja sagt in> der neuesten Version sind ein paar Fehler drin.
Nö, Widerspruch ist das keiner. Daß ein Programm (Compiler) fehlerhaft
ist, bedeutet nicht, daß der Fehler auch auftritt. Kleiner Exkurs in die
Aussagelogik :-)
Ansonsten wäre es übrigens auch ziemlich simpel, Fehlerfreiheit von
Software (oder wovon auch immer) nachzuweisen. Wenn man hingegen einen
Fehler erzeugt bekommt, weiß man, daß das Werkzeug fehlerhaft ist...aber
das ist wie gesagt was anderes: Es bedeutet nämlich, daß wenn das Tool
nicht fehlerhaft ist, man damit keine Fehler erzeugen kann.
Der Fehler ist in WinAVR-2009-03-13 und WinAVR-20080512 sowie in der
zugehörigen libgcc. Ob er in der avr-libc sein könnte weiß Jörg
wahrscheinlich besser, denn er kennt die gcc-Version mit dem er
generiert, die Patches die drinne sind und die Verschalterung.
Der Fehler ist nicht in Linux-Versionen, die aus den GCC-Quellen erzeugt
sind.
Johann
Mike S. wrote:
> Mit der 20090313 tritt der Fehler in meinem "Demo"Programm zumindestens> nicht mehr auf.
Es gibt ja nicht nur neue Bugs, sondern auch hin und wieder welche,
die repariert werden. ;-) Der hier ist ein solcher. (Wenn ich mich
recht erinnere, wurde falscher Code für Funktionen oberhalb 128 KiB
generiert, wenn mit -fcall-prologue compiliert worden ist, und die
avr-libc compiliert mit diesem Schalter.)
Jörg Wunsch wrote:
> Mike S. wrote:>>> Mit der 20090313 tritt der Fehler in meinem "Demo"Programm zumindestens>> nicht mehr auf.>> Es gibt ja nicht nur neue Bugs, sondern auch hin und wieder welche,> die repariert werden. ;-) Der hier ist ein solcher. (Wenn ich mich> recht erinnere, wurde falscher Code für Funktionen oberhalb 128 KiB> generiert, wenn mit -fcall-prologue compiliert worden ist, und die> avr-libc compiliert mit diesem Schalter.)
Ich meinte eher den hier:
http://lists.gnu.org/archive/html/avr-gcc-list/2009-03/msg00203.htmlhttp://lists.gnu.org/archive/html/avr-gcc-list/2009-04/msg00005.html
Die avr-libc wurde wahrscheinlich mit -O* und ohne -fno-split-wide-types
erzeugt?
Johann
