高效切换堆栈
由于某种原因，我切换了堆栈来调用应用程序中的某些函数。我使用 makecontext/getcontext/swapcontext 来实现此目的。但是，我发现它太慢了。 我尝试为此目的使用定制代码，该代码保存堆栈指针和其他寄存器，然后将堆栈指针分配给我想用作堆栈的新内存的值。但是，我不断收到检测到堆栈粉碎错误。
操作系统是否为堆栈设置了一些特殊权限，或者这里出了什么问题？如何规避这个问题。
Due to some reason, I switch the stack for calling some functions in my application. I use makecontext/getcontext/swapcontext for that purpose. However, I find it to be too slow.
I tried to use custom made code for that purpose, which saves the stack pointer and other registers and then assign the stack pointer the value of the new memory which I want to use as a stack. However, I keep getting stack smashing detected error.
Are there some special permissions set for the stack by the OS or else what is the matter here? How to circumvent the problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
优秀的 GNU Pth 库大量使用了这些技术。它有很好的文档记录，并确定了编译时最有效的上下文切换机制。 编辑：实际上是在配置时。
作者的论文：rse-pmt.ps 给出了用户空间上下文切换和相关问题的技术说明 - 替代信号堆栈等。
The excellent GNU Pth library makes heavy use of these techniques. It's very well documented, and determines the most efficient context switching mechanism at compile time. edit: at configure time actually.
The author's paper:
rse-pmt.psgives a technical account of user-space context switching and related issues - alternative signal stacks, etc.您可以看看其他软件是否有与您相同的肮脏伎俩。特别是鸡计划。在目标
jmp_buf上手动执行脏操作后，您可能会考虑使用longjmp。当然，这些都不是便携式的。但请更多地解释您的总体目标。你的问题一般都太神秘了......
（这对某些人来说是令人厌恶的）
You could look at other software doing the same dirty tricks as you do. In particular Chicken Scheme. You might perhaps consider using
longjmpafter manually doing dirty things on the targetjmp_buf. Of course, none of this is portable.But please explain more your overall goal. Your questions are generally too mysterious....
(and that is repulsive to some)
makecontext()/getcontext()/setcontext()/swapcontext() 非常高效，因为它们仅仅保存处理器寄存器的当前值。然而，至少在 Linux/GLIBC 中，setcontext() 和 getcontext() 会调用 rt_sigprocmask() 系统调用来保存/恢复信号调用线程的掩码。这可能是您面临一些性能问题的原因，因为这会触发上下文切换到内核。
The makecontext()/getcontext()/setcontext()/swapcontext() are quite efficient as they merely save the current values of the processor registers. However, in Linux/GLIBC at least, setcontext() and getcontext() invoke the rt_sigprocmask() system call to save/restore the signal mask of the calling thread. This may be the reason why you face some performance issues as this triggers a context switch into the kernel.