tool-conventions
tool-conventions copied to clipboard
Dynamic linking and stack pointer
DynamicLinking only describes how to load and initialize the loaded module's memory and table.
However, I wonder what about the stack pointer? I think there is a good reasons for reusing the same stack area for all linked modules.
Yes, the current plan is it use a single stack pointer shared between all modules. For the llvm backend this means we will depend on mutable global proposal as the stack pointer is stored in the global.
TBH, I'd not even considered the idea that they might have separate stack regions. I don't know of any other platform thats ever tried to do this. Normally the stack region is per-thread but shared between all code in the same process. Trying to have separate stack regions would make calling functions in other DLL hard as you'd you need to know in advance which DLL the function came from so you would know which stack to push args onto. I can't see any advantages to not sharing the stack. We already implicitly shared the (hidden) call stack.
TBH, I'd not even considered the idea that they might have separate stack regions. I don't know of any other platform thats ever tried to do this. Normally the stack region is per-thread but shared between all code in the same process. Trying to have separate stack regions would make calling functions in other DLL hard as you'd you need to know in advance which DLL the function came from so you would know which stack to push args onto. I can't see any advantages to not sharing the stack. We already implicitly shared the (hidden) call stack.
Yeah, exactly! I also think that sharing stack pointer is the way to go. The fact that aforementioned DynamicLinking.md doesn't contain any mentions of it made me think that there is some idea that I don't know of.
That's a good explanation, we could add a rationnal to the README, it seems valuable to me too.
Maybe DynamicLinking.md is a better place for such a note. I'll add it there if that makes sense?
Yes, thanks.