Im Programming Manual für den Cortex M4 steht (Abschnitt 2.1.3) "In an OS environment, it is recommended that threads running in Thread mode use the process stack and the kernel and exception handlers use the main stack." Es gibt also die zwei stacks. empfohlen wird die nutzung des einen für den kernel eines betriebssystems. der andere soll fuer threads genutzt werden. aber es steht nicht da, weshalb man das so machen soll. welche vorteile ergeben sich denn durch diese aufteilung?
Ein Userprozess ist generell nicht vertrauenswürdig und sollte daher nicht auf dem Kernelstack rumwutzen dürfen. Daher bekommt der Prozess nen eigenen.
hmm... aber welcher mechanismus verhindert denn auf dem cortex-m4 ein schreiben vom userprozess in den main stack???
Eine Trennung der Stacks ergibt hauptsächlich dann Sinn, wenn man mehrere Threads (Prozesse) hat, also beispielsweise in einem RTOS. Dann ist es recht sinnvoll, Interrupt-Handler automatisch auf dem Systemstack laufen zu lassen, statt auf dem Stack des grad laufenden und evtl. als Folge des Interrupts weggedrückten Threads.
hmm... jetzt sagst du auch dass es sinnvoll ist aber nicht warum. das letzte stueck deiner aussage hab ich nicht richtig verstanden "und evtl. als Folge des Interrupts weggedrückten Threads." könntest du das nochmal erklären danke schonmal fuer die antworten lg
sina anargo schrieb: > hmm... jetzt sagst du auch dass es sinnvoll ist aber nicht warum. Andernfalls müsstest du den Stack-Platz für sämtliche möglicherweise verschachtelten Interrupt-Handler auf jedem einzelnen Thread-Stack vorsehen. Mit getrennten Stacks statt dessen nur einmal.
ui... super, das macht sinn. dankööö
Gast
#3549993
sina anargo schrieb: > hmm... aber welcher mechanismus verhindert denn auf dem cortex-m4 ein > schreiben vom userprozess in den main stack??? Die MPU.
Gast
#3550737
Dr. Sommer schrieb: > Die MPU. Und wer kümmert sich bei einem M0 darum?
Gast
#3550759
no MPU schrieb: > Und wer kümmert sich bei einem M0 darum? Keiner, denn der ist nicht so für Multitasking und OSse ausgelegt.
Gast
#3550767
Dr. Sommer schrieb: > no MPU schrieb: >> Und wer kümmert sich bei einem M0 darum? > Keiner, denn der ist nicht so für Multitasking und OSse ausgelegt. Der hat keine zwei Stacks?
Gast
#3550774
no MPU schrieb: > Der hat keine zwei Stacks? doch, aber keine MPU. Daher nur "trusted"/"kooperatives" Multitasking, d.h. wenn man sicher ist dass die Anwendungsprogramme nicht mutwillig Unsinn machen.
Gast
#3550780
Dr. Sommer schrieb: > no MPU schrieb: >> Der hat keine zwei Stacks? > doch, aber keine MPU. Dr. Sommer schrieb: > sina anargo schrieb: >> hmm... aber welcher mechanismus verhindert denn auf dem cortex-m4 ein >> schreiben vom userprozess in den main stack??? > Die MPU. ??? Die Stackumschaltung hat nichst mit der MPPU zu tun. Und http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABDGADF.html sagt uns: Der user Prozess kann den Main Stack nutzen.
Gast
#3550791
no MPU schrieb: > Die Stackumschaltung hat nichst mit der MPPU zu tun. Richtig. > Und > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABDGADF.html > sagt uns: Der user Prozess kann den Main Stack nutzen. Es sei denn, man schützt ihn mit der MPU, falls vorhanden. Das macht Sinn, wenn man nicht-vertrauenswürdige Programme laden will.
Gast
#3550801
Dr. Sommer schrieb: > Es sei denn, man schützt ihn mit der MPU In welchem Modus wird festgelegt, welcher Stack zu verwenden ist? Wie kann ich zwischen den Modus wechseln?
Gast
#3550813
no MPU schrieb: > In welchem Modus wird festgelegt, welcher Stack zu verwenden ist? Der Stack kann jederzeit beliebig geändert werden (StackPointer-Register); unprivilegierter Code kann eben nur nicht auf geschützten Speicher zugreifen. > Wie > kann ich zwischen den Modus wechseln? Über CONTROL.nPRIV
Gast
#3550823
Dr. Sommer schrieb: > Der Stack kann jederzeit beliebig geändert werden Es kann in jedem Modus zwischen den beiden Stacks gewechselt werden?
Gast
#3550838
no MPU schrieb: > Es kann in jedem Modus zwischen den beiden Stacks gewechselt werden? Ja:
1 | |
2 | |
Lässt den Stackpointer auf die Adresse 42 zeigen. Wüsste übrigens keine Architektur unter der das nicht geht.
Gast
#3550889
Dr. Sommer schrieb: > Wüsste übrigens keine Architektur unter der das nicht geht. 6502. :-)
Gast
#3550891
Svenska schrieb: > 6502. :-) Achja, natürlich... Okay, sagen wir, alle Architekturen die Stack-Frames "unterstützen", d.h. den Stack für lokale Variablen und nicht nur für Rücksprungadressen nutzen, können das ;-)
Gast
#3550902
Dr. Sommer schrieb: > no MPU schrieb: > Es kann in jedem Modus zwischen den beiden Stacks gewechselt werden? > > Ja:mov r0, #42 > mov sp, r0 > > Lässt den Stackpointer auf die Adresse 42 zeigen. Wüsste übrigens keine > Architektur unter der das nicht geht. So,so,damit ist der Wechsel zwischen Main stack und process stack möglich?
Gast
#3550910
no MPU schrieb: > So,so,damit ist der Wechsel zwischen Main stack und process stack > möglich? Warum nicht? Ob das eine gute Idee ist ist eine andere Frage. Nur drauf schreiben/lesen kann man eben nicht falls die MPU entsprechend konfiguriert ist.
Gast
#3550914
Schon einmal auf einem M0 ausprobiert, ob das im unprivileged thread mode geht? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABDGADF.html Dann dem link MSR folgen.
Gast
#3550916
no MPU schrieb: > Schon einmal auf einem M0 ausprobiert, ob das im unprivileged > thread > mode geht? > > http://infocenter.arm.com/help/index.jsp?topic=/co... > Dann dem link MSR folgen. Da gibts keinen Link MSR. Recherchier doch einfach selber wenn du mir nicht glaubst, anstelle von 100 Detailfragen hintereinander zu stellen. Und sieh dir mal die Disassembly eines beliebigen kompilierten C-Programms an, und du wirst Dinge finden wie:
1 | |
und
1 | |
Was macht das wohl? Richtig, einfach einen durch gewöhnliche Arithmetik berechneten Wert in den Stack-Pointer schreiben. Das heißt, jedes ordinäre C Programm das lokale Variablen verwendet greift schreibend auf den Stack Pointer zu. Und das ist unabhängig vom Privileged-Mode; wär ja doof wenn unpriviligierte C-Programme keine lokalen Variablen verwenden könnten.
Gast
#3550918
Ich habe recherchiert und ARM schreibt, dass es nicht geht. Wenn du den links folgst, kommst du auch dahinter. Sonst probiert es aus und schaltet auf einem M0 zwischen Main und Prozess stack um.
Gast
#3550955
Bitte, wenn du das sagst. Einen M0 habe ich gerade nicht zur Hand. Aber wenn du meinst dass man den Stack Pointer nicht ändern kann, wie, glaubst du, funktionieren dann o.g. Assembler-Snippets? Dann würde ja kein C-Programm funktionieren.
Gast
#3552340
Dr. Sommer schrieb: > Dann würde ja > kein C-Programm funktionieren. ??? Beim Cortex M steht der akteulle SP im R13. Bei unterschiedlicher Konfiguration (main stack und process stack) wird beim Wechsel von unprivileged Thread in den Handler Mode der Stack oder umgekehrt automatisch umgeschaltet. Was gerade los ist steht im CONTROL register. Soll die Konfiguration verändert werden, muss man in einen privileged Mode wechseln. Kannst du alles unter den links nachlesen. Und das ist die Antwort auf die Ausgangsfrage: sina anargo schrieb: > hmm... aber welcher mechanismus verhindert denn auf dem cortex-m4 ein > schreiben vom userprozess in den main stack??? Natürlich kann ich mit einem Pointer beliebig im Speicher rühren. Das verhindert die MPU. Aber das war nicht die Frage.
Gast
#3552433
no MPU schrieb: > Bei unterschiedlicher > Konfiguration (main stack und process stack) wird beim Wechsel von > unprivileged Thread in den Handler Mode der Stack oder umgekehrt > automatisch umgeschaltet. Was gerade los ist steht im CONTROL register. > Soll die Konfiguration verändert werden, muss man in einen privileged > Mode wechseln. Ja, den Modus nur so. Aber den Stack Pointer kann man trotzdem manuell auf was anderes zeigen lassen, wenn die MPU es nicht verhindert. no MPU schrieb: > Kannst du alles unter den links nachlesen. Warum fragst du erst jedes Bisschen nach, um es dann doch selber rauszusuchen und mir zu erklären was ich angeblich falsches geschrieben habe?
Gast
#3552471
Dr. Sommer schrieb: > Warum fragst du erst jedes Bisschen nach, um es dann doch selber > rauszusuchen und mir zu erklären was ich angeblich falsches geschrieben > habe? Ich habe nicht gefragt, sondern wollte dich zum Denken anregen. Das hat du nicht gemerkt? Die Links sind als Hilfe für dich gedacht. Wenn man hier nur so schreibt, glaubt es keiner.
Gast
#3552526
no MPU schrieb: > Ich habe nicht gefragt, sondern wollte dich zum Denken anregen. Das hat > du nicht gemerkt? AHAHa, und ich dachte du trollst nur. Vielen Dank für deine Erleuchtung, sonst verbringe ich meine Tage immer in gedankenloser Finsternis! > Die Links sind als Hilfe für dich gedacht. Wenn man hier nur so > schreibt, glaubt es keiner. Ich habe die ARMv6/7 Architecture Reference Manuals sogar als PDF und ich hatte da alles schon vorher nachgelesen, keine Sorge.