[WinAVR 20080402rc1] Bug

[Andreas A. (Firma: Embedded Microtec) (andi)]

Hallo,

  hier im Forum sind ja auch immer wieder Leute unterwegs, die aktiv am 
(Win)AVR-GCC Projekt mitarbeiten... ich denke nämlich, dass es im 
aktuellen Release Candidate von WinAVR (WinAVR 20080402rc1) einen Bug 
gibt.

Und zwar passiert folgendes:
Wenn als Optimierungsflag 's' angegeben wird, ersetzt der Linker 
anscheinend die Adressen falsch. Im .lss File sind dann Funktionen 
teilweise durcheinander gewürfelt und die Sprungadressen stimmen nicht 
mehr.

Z.B.: Aus dem C Code

  while(PINA & _BV(PA0));

wird im .lss File

 11c:  00 99         sbic  0x00, 0  ; 0
 11e:  dd cf         rjmp  .-70       ; 0xda <main+0x4>

Deshalb wird mein Controller auch ständig resetiert. Wenn die 
Optimierung ausgeschaltet wird, passt alles!

mfg
Andreas

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

Erstens solltest du Probleme mit der Betaversion an Eric direkt
berichten bzw. als Bug beim sourceforge.net-Projekt von WinAVR
abkippen.

Zweitens kann man aus dem kurzen Fragment rein gar nichts ersehen.
Der Compiler kann völlig korrekt gearbeitet haben, aber es könnte
auch ein Bug sein.

[Andreas A. (Firma: Embedded Microtec) (andi)]

Na gut... dann wende ich mich direkt an Eric bzw. dem SF.net Projekt.

Und BTW. das Codefragment sollte lediglich darstellen, dass der Sprung 
nicht an die richtige Position geht. Der Sprung sollte auf Adresse 0x11c 
und nicht auf 0xda gehen.

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

Andreas Auer wrote:

> Und BTW. das Codefragment sollte lediglich darstellen, dass der Sprung
> nicht an die richtige Position geht. Der Sprung sollte auf Adresse 0x11c
> und nicht auf 0xda gehen.

Das ist keineswegs zwangsweise so.  Du hast einfach ein Stück
rausgerissen und irgend jemand (OK, avr-objdump) hat dir eine Zeile
Sourcecode daneben gemalt.  Welchen Zusammenhang die beiden wirklich
haben, kann man erst entscheiden, wenn man alles dazu sieht.

Also wie geschrieben: ich bin erstmal gar nicht davon überzeugt, dass
du überhaupt einen Bug hast, sondern der Optimizer hat den Code nur
anders sortiert, als das früher mal der Fall war.  Aber wenn du nicht
den gesamten (relevanten) Code dafür zeigen möchtest, kann ich dir
auch nicht helfen.

[Andreas A. (Firma: Embedded Microtec) (andi)]

Das ist mir schon klar, dass es möglich ist, dass der Optimizer den Code 
neu sortieren kann bzw. auch Funktionsaufrufe durch Inline Funktionen 
ersetzen kann. Für die oben angeführte einfache Schleife sollten aber 
dennoch die beiden Zeilen ausreichen und der Sprung richtig sein.

Aber zur Vollständigkeit hier noch der gesamte C Code meiner "main" und 
das .lss File dazu:

int main(void)
{
  unsigned char buffer[RECORD_BUFFER_SIZE];
  unsigned char key = 0;
  unsigned char last_key = 0;
  unsigned char state = STATE_IDLE;

  unsigned int address;
  unsigned int address_max;
  unsigned int buffer_count;
  unsigned int i;

  usartInit(12);
  usartPutLine("Siren Recorder");
  
  keyledInit();
  flashInit();
  mp3Init();

  while(PINA & _BV(PA0));
  usartPutLine("Normal");
  while(PINA & _BV(PA0));
  usartPutLine("Normal");

  while(1);
  return 0;
}

int main(void)
{
      d6:  8c e0         ldi  r24, 0x0C  ; 12
      d8:  90 e0         ldi  r25, 0x00  ; 0
      da:  0e 94 2c 06   call  0xc58  ; 0xc58 <usartInit>
  unsigned int address_max;
  unsigned int buffer_count;
  unsigned int i;

  usartInit(12);
  usartPutLine("Siren Recorder");
      de:  80 e0         ldi  r24, 0x00  ; 0
      e0:  91 e0         ldi  r25, 0x01  ; 1
      e2:  0e 94 55 06   call  0xcaa  ; 0xcaa <usartPutLine>
  
  keyledInit();
      e6:  0e 94 aa 05   call  0xb54  ; 0xb54 <keyledInit>
  flashInit();
      ea:  0e 94 83 05   call  0xb06  ; 0xb06 <flashInit>
  mp3Init();
      ee:  0e 94 1c 08   call  0x1038  ; 0x1038 <mp3Init>

  while(PINA & _BV(PA0));
      f2:  00 99         sbic  0x00, 0  ; 0
      f4:  f2 cf         rjmp  .-28       ; 0xda <main+0x4>
  usartPutLine("Normal");
      f6:  8f e0         ldi  r24, 0x0F  ; 15
      f8:  91 e0         ldi  r25, 0x01  ; 1
      fa:  0e 94 55 06   call  0xcaa  ; 0xcaa <usartPutLine>
  while(PINA & _BV(PA0));
      fe:  00 99         sbic  0x00, 0  ; 0
     100:  ec cf         rjmp  .-40       ; 0xda <main+0x4>
  usartPutLine("Normal");
     102:  8f e0         ldi  r24, 0x0F  ; 15
     104:  91 e0         ldi  r25, 0x01  ; 1
     106:  0e 94 55 06   call  0xcaa  ; 0xcaa <usartPutLine>
     10a:  ff cf         rjmp  .-2        ; 0x10a <main+0x34>
  }
}

Und jetzt sag mir bitte nochmal dass die beiden Sprünge richtig sind! 
Das sind sie nämlich unter Garantie nicht (und das war auch der Grund 
warum mein Controller sich immer wieder resetiert hat).

mfg
Andreas

[Roland Schmidt (Gast)]

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=428028#428028

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

Andreas Auer wrote:

> Und jetzt sag mir bitte nochmal dass die beiden Sprünge richtig sind!

In dem Zusammenhang ist es klar, dass sie es nicht sind.

Roland hat es ja gefunden.  Was auch immer da reingerutscht war...

[Andreas A. (Firma: Embedded Microtec) (andi)]

Jop... anscheinend wurde das schon entdeckt und behoben... wunderbar!