何らかの理由で、アプリケーションの一部の関数を呼び出すためにスタックを切り替えます。その目的のためにmakecontext/getcontext/swapcontextを使用します。しかし、遅すぎると思います。その目的のためにカスタムメイドのコードを使用しようとしました。これは、スタックポインターと他のレジスターを保存してから、スタックとして使用する新しいメモリの値をスタックポインターに割り当てます。ただし、スタックスマッシングで検出されたエラーが発生し続けます。
OSによってスタックに設定された特別な権限がありますか、それともここで問題はありますか？問題を回避する方法。
優れたGNUPthライブラリは、これらの手法を多用しています。これは非常によく文書化されており、コンパイル時に最も効率的なコンテキスト切り替えメカニズムを決定します。編集：実際の構成時に。
著者の論文：rse-pmt.psユーザースペースのコンテキストスイッチングと関連する問題（代替信号スタックなど）の技術的な説明を提供します。
あなたはあなたがするのと同じ汚いトリックをしている他のソフトウェアを見ることができます。特にチキンスキーム。longjmpターゲットに対して手動でダーティなことを行った後に使用することを検討するかもしれませんjmp_buf。もちろん、これはどれもポータブルではありません。
しかし、あなたの全体的な目標についてもっと説明してください。あなたの質問は一般的にあまりにも神秘的です....（そしてそれは一部の人には反発的です）
makecontext （） / getcontext（） / setcontext（） / swapcontext（）は、プロセッサレジスタの現在の値を保存するだけなので、非常に効率的です。ただし、少なくともLinux / GLIBCでは、setcontext（）とgetcontext（）がrt_sigprocmask（）システムコールを呼び出して、呼び出し元のスレッドのシグナルマスクを保存/復元します。これが、カーネルへのコンテキストスイッチをトリガーするため、パフォーマンスの問題に直面する理由である可能性があります。