Forum: Compiler & IDEs unplanmäßige Sprünge? - debuggen mit avr-gdb und simulavr


von Mike W. (Firma: - private -) (mike_w995)


Lesenswert?

Hallo zusammen,

ich versuche ein kleines Programm für den mega8 mit simulavr und avr-gdb 
zu debuggen.

Gemacht habe ich bisher folgendes:

Kompilieren main.elf,
Simulator starten mit
1
simulavr -G -d atmega8  -F 8000000 -f main.elf

Debugger starten
1
 avr-gdb --tui --se main.elf

im gdb:
1
 
2
target remote :1212 
3
load
4
b main
5
c

Funktion main() aus main.c sieht so aus ..
1
int main( void )
2
{
3
   
4
   OwContext o;
5
   uint8_t B = 0 ; 
6
7
   /* for debugging use variables instead of in/out-registers
8
    */
9
   volatile uint8_t _ddrd , _portd, _pind ;  
10
11
 
12
   uart_init();
13
   OwInit();
14
15
   DDRD = 0x00 ; // alles Eingänge
16
   PORTD = 0xFF;  // Pullups AN
17
18
   while( 1 ) {
19
20
      uint8_t i, j;
21
      
22
//      if ( ~PIND & (1<<PD7) ) {  // Taster gedrückt
23
        _pind = PIND;              // für Debug PIND in Variable laden um im gdb ändern zu können 
24
        if ( ~_pind & (1<<PD7) ) {
25
           
26
         if ( ~B & 0x80 ){        // Taster war zuvor noch nicht gedrückt
27
            B |= 0x80 ;           // merken
28
            uart_putc('*');
29
            i = OwSearchRom( &o ) ;
30
            
31
            uart_putc(i);
32
            
33
         }
34
      } else {
35
         if ( B & 0x80 ){        // Taster war zuvor noch nicht gedrückt
36
            B &= ~0x80 ;           // merken
37
         }
38
      }
39
      
40
   }
41
      
42
  return 0;
43
}

Das alles erstmal nur zur Kenntnis. Nun das Problem:

Beim Steppen durch die Funktion main wird das Programm nicht 
nacheinander abgearbeitet, so wie die Befehlszeilen nacheinander folgen.
zB wird die Anweisung "uint8_t B = 0 ; " vom Beginn erst nach "PORTD = 
0xFF" angesprungen , um dann mit der Anweisung "B &= ~0x80 ; " etliche 
Zeilen weiter unten fortzufahren und dann weiter mit "B |= 0x80 ;" 
weiter oben weiter zu machen.
Ich kann dieser Logik nicht ganz folgen, weil ich davon ausgehe, dass 
mit dem gdb-Kommando "s" eine tatsächlich schrittweise Abarbeitung 
stattfindet.

Nun bin ich etwas ratlos - sollte das Programm tatsächlich in dieser Art 
ausgeführt werden, weiß ich zum einen nicht warum und zum anderen 
wundert es nicht, dass es sich nicht wie erwartet verhält.

<br>
Hat jemand ne Idee, wie dieses scheinbar wahllose Umherspringen zustande 
kommt ? Muss das so?


Für Ideen dankbar

Mike

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Geschieht das auch, wenn ds Progamm mit -O0, -O1 oder -Og übersetzt 
wird?

: Bearbeitet durch User
von Mike W. (Firma: - private -) (mike_w995)


Lesenswert?

Hallo,

also ich habe das mit -O1 und mit -Os probiert ohne Unterschiede 
festzustellen.

von Mike W. (Firma: - private -) (mike_w995)


Lesenswert?

.. ach ja und kompiliert ist mit -gdwarf-2

von Rolf M. (rmagnus)


Lesenswert?

Johann L. schrieb:
> Geschieht das auch, wenn ds Progamm mit -O0

Mike W. schrieb:
> also ich habe das mit -O1 und mit -Os

Aber nicht mit -O0?
Der Grund für die vermeintlichen Sprünge ist sehr wahrscheinlich die 
Optimierung. Der Optimizer sortiert deinen Code bei der Optimierung um. 
Deshalb passiert die Ausführung auf dem Prozessor nicht mehr in der 
Reihenfolge, wie sie im Quellcode angegeben ist. Es gibt dann oft nicht 
einmal mehr eine direkte 1:1-Zuordnung von Codezeilen zu Passagen im 
erzeugten Binärcode.

von Christopher J. (christopher_j23)


Lesenswert?

Sehe ich auch so. Zwischen -O0 und -O1 liegen Welten was die 
Debugbarkeit angeht. Empfehlen würde ich -Og, wenn dein Compiler es 
unterstützt. Außerdem empfiehlt sich noch -g3, dann kannst du auch 
#defines "dereferenzieren", z.B. PORTB, DDRB, etc. Im " layout asm" 
kannst du dann mit "si" durch einzelne Instruktionen springen, weil 
ansonsten natürlich eine Zeile C mehrere ASM-Zeilen sein kann.

von Mike W. (Firma: - private -) (mike_w995)


Lesenswert?

Hallo zusammen,

danke erstmal für eure Hinweise und Anregungen.

Mit -O0 zu compilieren schlägt leider fehl, weil die .text-section nicht 
mehr in den mega8 passen würde. Ich weiß nicht, ob man das irgendwie 
abschalten kann und ob der simulator das nachher trotzdem nimmt. 
Alternative wäre sicher, einen andere, ähnliche mcu für das Debuggen zu 
nehmen, die mehr Speicher hat. Mit -Os bleiben ja immerhin ~1,3kB Code 
übrig.

Aber was Christopher schreibt, leuchtet mir schon ein. Hab mir mal das 
Listing angeschaut, davon war mir nachher auch schwindlig ^^

Mit "-Og -g3 -gdwarf-2"  komm ich auf 1488Byte. Das sollte laufen. 
Testen kann ich das erst heute Abend ..  ich berichte ..

Gruß

Mike

von Mike W. (Firma: - private -) (mike_w995)


Lesenswert?

Hallo Leute,

vielen Dank nochmal für eure Tipps.

Mit den Debug-Einstellungen hats dann viel besser geklappt.
Ich hab jetzt auch so ein DevBoard mit ATmega32 und JTAG, da werde ich 
das auch mal mit avarice als ICE versuchen, dann kann ich auch live mit 
allen Sensoren und Aktoren testen. Es bleibt spannend.

Gruß

Mike

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.