GCC Discarded Section in Disassembly

[Leopold N. (leo_n)]

Ich habe folgendes Problem:

Die Funktion CNC::waitForPositionMatch() wird im Linker als Discarded 
markiert. Das ist auch richtig so, aber diese Funktion taucht im 
Disassembly beim Debuggen an der Adresse 0x0 wieder auf und zersört mir 
dort meinen Code, da an Adresse 0x0 eigentlich ein Handler steht. Das 
Symbol taucht im disassembly wieder auf, obwohl es dort eigentlich gar 
nicht exisiteren dürfte.
Der Build Analyzer weiß auch nichts von der Funktion. Eigentlich sollte 
an Adresse 0x0 die ISR_TIMER_2 stehen, aber das Symbol ISR_TIMER_2 
taucht dort nicht auf. Wenn ich im Disassembly nach dem Symbol 
ISR_TIMER_2 suche, springt er schon an die richtige Adresse, nur steht 
dort CNC::waitForPositionMatch.
Woran kann das liegen? Ist das ein Bug?
Im Speicher bei 0x08000000 (Vector Table, ist ein STM32) ist auch die 
richtige Sprungadresse zu ISR_TIMER_2 eingetragen (genaue Adresse 
0x080000B0).
Das eigentliche Problem ist jetzt allerdings, dass irgendwie eine 
undefined-Instruction in dem ganzen Wirrwarr mitmischt, die mich in 
einen Usage-Fault laufen lässt (dürfte an 0x4 sein).

Wenn ihr noch mehr Infos braucht, bitte fragen.
Grüße

[Programmierer (Gast)]

Leopold N. schrieb:
> da an Adresse 0x0 eigentlich ein Handler steht

Leopold N. schrieb:
> Eigentlich sollte
> an Adresse 0x0 die ISR_TIMER_2 stehen,

Nö, da gehört der ISR-Vektor hin, an dessen Anfang der initiale 
Stack-Pointer steht, denn bei 0x0 ist der Programmspeicher abgebildet, 
d.h. entweder 0x08000000 für Flash oder 0x20000000 für RAM (je nach 
BOOT-Pins).

In disassembly.PNG sieht es auch nicht so aus als würde bei 0x0 
sinnvoller Code stehen. Das ist vermutlich der fehl-disassemblierte 
ISR-Vektor.

Leopold N. schrieb:
> Wenn ich im Disassembly nach dem Symbol
> ISR_TIMER_2 suche, springt er schon an die richtige Adresse, nur steht
> dort CNC::waitForPositionMatch.

Das kann sein, macht aber nichts - der Debugger zeigt einfach den Namen 
des ersten Symbols an, was die Adresse hat. Wenn beide Symbole die selbe 
Adresse haben, was sein kann wenn das eine einen Default-Wert hat, steht 
da ggf. das falsche Symbol. Das ist aber nicht weiter schlimm.

Leopold N. schrieb:
> Das eigentliche Problem ist jetzt allerdings, dass irgendwie eine
> undefined-Instruction in dem ganzen Wirrwarr mitmischt

Versuchst du Adresse 0x0 auszuführen an welcher sich wie gesagt der 
ISR-Vektor befindet?

Zeig ein minimales reproduzierbares Beispiel, mit Linker Script, 
Makefile & Startup-Code, sonst ist das alles nur raten.

[Leopold N. (leo_n)]

Also: Boot Pins stehen auf Execution from Flash und Vector Table startet 
an 0x08000000. Mit Offset 0xB0 steht dann der Vector ISR_TIMER_2, wie in 
memory.png zu sehen.

Anbei mal das Linker Script und der Startup-Code, Makefile ist das 
Standardmakefile der STM32CubeIDE für ein STM32 Projekt.

[Programmierer (Gast)]

Leopold N. schrieb:
> Makefile ist das
> Standardmakefile der STM32CubeIDE für ein STM32 Projekt.

Hab ich nicht installiert, kann ich nicht testen...

Achso, du hast den ITCM an Adresse 0, dann macht das schon eher Sinn. 
Ich glaube dass waitForPositionMatch bei 0 angezeigt wird ist völlig 
egal. Prüfe mal ob der Code auch wirklich korrekt in den ITCM kopiert 
wird (Memory Dump von Adresse 0x0), und ob man den nicht vorher 
einschalten muss, und ob deine CPU (Cortex-M7?) da vielleicht noch eine 
"dsb" und "isb" vor dessen Ausführung und einen Cache-Flush haben 
möchte. Führe mal testweise eine normale Nicht-ISR-Funktion aus dem ITCM 
aus.

[Leopold N. (leo_n)]

ITCM muss man nicht einschalten. Das komische ist, dass ähnlicher Code 
bereits vorher funktioniert hat. ISR aus dem ITCM ausführen hatte bisher 
problemlos geklappt.
Mich verwirrt vorallem, wie eine Funktion, die in der Linker Stage 
eliminiert wurde, im elf-File auftauchen kann.

Cache benutze ich momentan noch nicht. DSB oder ISB wird nicht benötigt.

Nicht-ISR Funktionen führe ich massenweise aus dem ITCM aus. 
Funktionieren alle tadellos. Die gesamte .code_sram Section wird aus dem 
ITCM ausgeführt und passt problemlos.
Ich werde trotzdem gleich nochmal checken, ob der Code richtig kopiert 
wird.
Aber selbst wenn nicht, gibt es dann immernoch ein Problem mit der Debug 
Information.

[Leopold N. (leo_n)]

Hier nochmal der Memory vor und nach dem Kopieren des Codes aus dem 
Flash.
Sieht passend aus.

[Programmierer (Gast)]

Leopold N. schrieb:
> Mich verwirrt vorallem, wie eine Funktion, die in der Linker Stage
> eliminiert wurde, im elf-File auftauchen kann.

Sicher dass sie da überhaupt auftaucht, und nicht einfach nur das Symbol 
die Adresse 0 hat und da noch angezeigt wird, während da aber 
tatsächlich der gewünschte Code der ISR ist? Die Debugging-Tools sind 
nicht wirklich darauf ausgelegt, dass an 0x0 valider Code steht.

Leopold N. schrieb:
> DSB oder ISB wird nicht benötigt.

Das braucht man auch ohne Cache. Die Prozessor-Pipeline kann man 
schließlich nicht abschalten.

Leopold N. schrieb:
> gibt es dann immernoch ein Problem mit der Debug
> Information.

Was für eins?

Leopold N. schrieb:
> Hier nochmal der Memory vor und nach dem Kopieren des Codes aus
> dem
> Flash.
> Sieht passend aus.

Zeig mal die Ausgabe von "arm-none-eabi-objdump -s -d -j .code_sram", 
dann kann man das vergleichen. Und zeig den Code der ISR. Steppe im 
Single-Instruction-Modus durch den Code und finde die Stelle, an der es 
crasht. Es ist sehr verdächtig, dass in disassembly.PNG kaputter 
Assembler-Code zu sehen ist.

[Leopold N. (leo_n)]

Bin dem Problem schon auf der Spur...typisches Nullpointer 
Problem...habe den Code gefunden, der zwischen dem Startup und der ISR 
das erste Word an Adresse 0x0 durch einen Nullpointer 
überschreibt...eigentlich habe ich per MPU nur privilegierte Software 
den Zugriff auf 0x0 erlaubt, aber es ist leider auch privilegierter 
Code, der da Mist baut. Ist durch eine Änderung in meinem Betriebssystem 
passiert, bei der ich wohl vergessen habe, auch entsprechende andere 
Stellen im Code anzupassen.

Damit dürfte das Problem gegessen sein.
Dankeschön

[Programmierer (Gast)]

Leopold N. schrieb:
> eigentlich habe ich per MPU nur privilegierte Software
> den Zugriff auf 0x0 erlaubt,

Erlaube am Besten überhaupt keiner Software den Schreibzugriff darauf, 
nachdem der Startupcode das schon initialisiert hat. Na dann hat's sich 
ja geklärt :)

[Leopold N. (leo_n)]

Programmierer schrieb:
> Leopold N. schrieb:
>> eigentlich habe ich per MPU nur privilegierte Software
>> den Zugriff auf 0x0 erlaubt,
>
> Erlaube am Besten überhaupt keiner Software den Schreibzugriff darauf,
> nachdem der Startupcode das schon initialisiert hat. Na dann hat's sich
> ja geklärt :)

Stimmt eigentlich...gar keine so schlechte idee, hätt ich auch selbst 
drauf kommen können :)

Vielen Dank für deine Bemühungen und schnellen Antworten.