String als Parameter übergeben

[J. V. (janvi)]

irgendwo habe ich mal gehört, daß in C der String als Zeiger auf char 
implementiert ist.

void LCD_Print (char* string)
{volatile uint8_t debugvar;
 
 debugvar = *string;      // debugvar sollte jetzt 0x31 enthalten
 string++;
 debugvar = *string;      // sollte jetzt 0x32 enthalten
}

Nun gibt es das Problem, das beim Aufruf LCD_Print("123") weder eine 
Fehlermeldung noch ein Code abgesetzt wird. Wahrscheinlich habe ich mehr 
als einen Fehler ?

[abc123 (Gast)]

J. V. schrieb:
> Nun gibt es das Problem, das beim Aufruf LCD_Print("123") weder eine
> Fehlermeldung noch ein Code abgesetzt wird.
Warum auch? Passt alles, nur das volatile ist vermutlich überflüssig.

[Peter II (Gast)]

woran sieht du das er nicht das macht was du erwartest?

[Noname (Gast)]

Es wohl so sein, das der Compilder das Ganze völlig wegoptimiert.

Unklar ist mir die Formulierung: "... noch ein Code abgesetzt wird."
Was ist damit gemeint?

Es scheint als wenn Du einen gewissen Fehler finden willst und das Dein 
Versuch war. Zeig mal den Code den Du eigentlich zum laufen bringen 
willst und beschreibe, was nicht funktioniert.

[Klaus W. (mfgkw)]

abc123 schrieb:
> das volatile ist vermutlich überflüssig.

Zum Debuggen mag es sinnvoll sein; wenn die Variable sonst nicht 
verwendet wird könnte sie wegoptimiert werden und dann sieht man beim 
Debuggen nichts.

[J. V. (janvi)]

habe einen Debugger wo ich an der LCD_Print ("123") Zeile keinen 
Breakpoint setzen kann weil es keinen Code dazu gibt. Volatile habe ich 
genommen damit der Compiler nichts wegoptimieren soll. Im Disassembly 
sieht man aber, daß GCC den Funktionscode direkt einsetzt und nicht 
aufruft, weil er schnallt daß er nur einmal verwendet wird. Soweit wäre 
das also noch korrekt. Bei den debugvar Zuweisungen kann ich auch eine 
Breakpoint setzen, blos kommt er dort nicht an. Da muß ich doch mal das 
Disassembly näher anschauen

[J. V. (janvi)]

ok, tut tatsächlich. Es scheint als ob GCC trotz volatile bei einem 
späteren Optimierungslauf die Zugriffe auf dem Stack wegoptimiert. Wenn 
ich tatsächlich auf das LCD zugreife, geht es und auch der Aufruf 
erzeugt wie erwartet einen Code (wo sich auch ein Breakpoint sezten 
lässt)

[Johann L. (gjlayde)]

J. V. schrieb:

> Es scheint als ob GCC trotz volatile bei einem späteren
> Optimierungslauf die Zugriffe auf dem Stack wegoptimiert.

Was heißt "scheint"?

Und was meinst du mit "späterem Optimierungslauf"? Schaust du dir 
GCC-Zwischencode an?

Was die Anzeige von (weg-)optimiertem Code im Debugger angeht: mit 
zeitgemäßem Debug-Format geht auch das, etwa -gdwarf-4

[Janvi (Gast)]

Die Optimierung hat versehentlich auf -Os (für Size) gestanden weil die 
Datei später zum Projekt hinzugefügt wurde. Seit die Optimierung am GCC 
abgeschaltet ist, tut auch der Debugger wieder wie erwartet.
Leider bin ich erst zu spät darüber gestolpert, wie auch bei anderen HLL 
Einzelschritt Vorgängen Unregelmässigkeiten aufgetreten sind. Momentan 
habe ich nur gdwarf-2 (cc1: error: unrecognised debug output level 
"dwarf-4")

Die Version soll glaube ich auch in Zeilen mit For-Schleife zwischen den 
einzelnen Strichpunkten steppen können (?) Irgendwann werde ich aber 
wohl mal auf eine neuere Version umsteigen - Empfehlungen für einen 
passenden Debugger sind willkommen (STM32 mit SWD Interface)

[Johann L. (gjlayde)]

Janvi schrieb:
> Die Optimierung hat versehentlich auf -Os (für Size) gestanden weil die
> Datei später zum Projekt hinzugefügt wurde. Seit die Optimierung am GCC
> abgeschaltet ist, tut auch der Debugger wieder wie erwartet.

Die Optmierung für's Debuggen zu deaktivieren ist eine schlechte Idee, 
wenn die Produktiv-Code mit anderen Optionen erzeugt wird. Dann debuggst 
du nämlich i.w. Märchencode, der mit dem letzendlich ausgeführten Code 
nicht viel gemein hat.

Zur Fehlersuche immer das Untersuchen, was relevant ist!

Debugging/Simulation zu verwenden um den eigenen Code zu 
reverse-engineeren weil man "irgendwo mal was über C gehört hat" ist 
mindestens grenzwertig.

Merke: wo Engineering möglich ist, hat man ziemlich sicher etwas 
verbockt, wenn man stattdessen Reverse-Engineering betreibt...

> Leider bin ich erst zu spät darüber gestolpert, wie auch bei anderen HLL
> Einzelschritt Vorgängen Unregelmässigkeiten aufgetreten sind.

> cc1: error: unrecognised debug output level "dwarf-4"

hmm... selbst die älteste noch supportete GCC-Version (4.5, inzwischen 
seit über 3 Jahre releast) unterstützt bereits DWARF-4.

Und zwischen DWARF-2 und DWARF-4 gibt's immerhin noch DWARF-3.