String als Parameter übergeben

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.

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

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)

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