<div dir="ltr">Thanks for the clarification.<br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 12, 2018 at 3:09 PM <<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 12 Nov 2018 02:00:02 +0800, Carter Cheng said:<br>
> Thanks for the reply but the link doesn't quite answer the question. I am<br>
> wondering how the pointer is handled so that there is one per thread by the<br>
> compiler. I perhaps was under the perhaps mistaken impression that the<br>
> stack pointer frame pointer management inside the compiler makes certain<br>
> assumptions in user space- but i am unsure how this applies to kernel space.<br>
<br>
For regular function calls, a kernel stack works exactly the same as a function<br>
stack in userspace (remember, it's the same compiler, and other tools like the<br>
linker and gdb need to be able to understand function calls).<br>
<br>
Where things are different are what happens if an interrupt or a call to<br>
schedule() or enter/exit the kernel (or a few other similar situations I can't<br>
remember at 2AM) causes a different thread to start running - for those cases,<br>
there's architecture-dependent shim code (usually involving at least a bit of<br>
assembler) to do the register swapping needed.<br>
<br>
</blockquote></div>