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.
sina anargo schrieb: > hmm... aber welcher mechanismus verhindert denn auf dem cortex-m4 ein > schreiben vom userprozess in den main stack??? Die MPU.
no MPU schrieb: > Und wer kümmert sich bei einem M0 darum? Keiner, denn der ist nicht so für Multitasking und OSse ausgelegt.
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?
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.
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.
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.
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?
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
Dr. Sommer schrieb: > Der Stack kann jederzeit beliebig geändert werden Es kann in jedem Modus zwischen den beiden Stacks gewechselt werden?
no MPU schrieb: > Es kann in jedem Modus zwischen den beiden Stacks gewechselt werden? Ja:
1 | mov r0, #42 |
2 | mov sp, r0 |
Lässt den Stackpointer auf die Adresse 42 zeigen. Wüsste übrigens keine Architektur unter der das nicht geht.
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 ;-)
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?
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.
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.
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 | b087 sub sp, #28 |
und
1 | ac03 add r4, sp, #12 |
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.
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.
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.
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.
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?
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.