Fehler/Problem mit sprintf

[Mike R. (thesealion)]

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.

#include "main.h"

char buffer[101];

int main( )
   {
   PORTH.DIR = 0xFF;    // kompletten Port als Output schalten
   PORTH.OUT = 0x55; 

   for (;;)
      {
      PORTH.OUT = 0x00;   
      test();
      }
   }

main.h

#ifndef __main__
   #define __main__

   #include <stdlib.h>
   #include <avr/io.h>
   #include <stdlib.h>
   #include <avr/interrupt.h>

   #include <stdio.h>
   #include <stdint.h>
   #include "test.h"


   extern char buffer[101];

#endif

test.h

#include <stdlib.h>
#include <avr/io.h>
#include <stdlib.h>
#include <avr/interrupt.h>

#include <stdio.h>
#include <stdint.h>


void test(void);

test.c

#include "main.h"
#include "test.h"


void test(void)
{
sprintf(buffer, "%d, %d",  0, 6);
 
}

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.

[P. S. (Gast)]

Welcher Controller?

[Mike R. (thesealion)]

Ups, vergessen:

Xmega128A1

[Karl H. (kbuchegg)]

Mike S. wrote:
> Ups, vergessen:
>
> Xmega128A1

Der hat nicht zufällig eine M103 Fuse?
Wenn ja: abschalten! Sonst geht jeder Funktionsaufruf in die Hose

[Mike R. (thesealion)]

Hat er leider nicht. Außerdem bekomme ich den Fehler sogar im Simulator 
reproduziert und zumindestens der sollte keine passenden Fuses haben.

[Karl H. (kbuchegg)]

Ja, habs gerade bemerkt. Hab das 'X' überlesen.

An deinem Pgm ist so erst mal nichts falsch.

[Johann L. (gjlayde)]

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

[Mike R. (thesealion)]

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

[Johann L. (gjlayde)]

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

[Jörg W. (dl8dtl) (Moderator)]

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.)

[Johann L. (gjlayde)]

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.html
   http://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