問題タブ [setjmp]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c - longjmp(buffer, 0) が 0 を返さない
setjmp/longjmp を使用して簡単なことをしようとしています。ユーザーに Enter キーを何度も押すように依頼し、ユーザーが何か他のものを挿入すると、longjmp を使用してプロセスを再起動します。
カウンターを使用して機能するかどうかを確認しています。このカウンターは開始時に0ですが、longjmpを使用するとカウンターは1から再開します。
出力：
このコードがばかげていることはわかっています。単純な例で setjmp/longjmp を使用しようとしています。
linux - getcontext と setjmp が glibc-x86-64 で異なるレジスタを保存するのはなぜですか?
ソースコードは次のとおりです: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/unix/sysv/linux/x86_64/getcontext.S;hb=HEAD https:// sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdeps/x86_64/setjmp.S;hb=HEAD
ご覧のとおり、getcontext は浮動小数点コンテキストも保存し、r8 と r9 を登録しますが、setjmp は保存しません。これの理由は何ですか？
c - それを呼び出す関数ではなく、メインに戻る方法は?
をfunction()呼び出す がありますanotherFunction()。の内部anotherFunction()には、if満たされたときに に戻り、 にmain()ではなく戻るステートメントがありますfunction()。これどうやってやるの？
c++ - 一貫性のない警告: 変数は「longjmp」または「vfork」によって破壊される可能性があります
私は g++ 4.8.3 のバグに遭遇したとほぼ確信していましたが、setjmp/longjmp の経験がほとんどないため、最初にこのリストを尋ねようと思いました。問題のコードを次の foo.cxx に単純化しました。
このコードをコンパイルするには、g++ 4.8.3 を使用します。私にとって興味深いのは、USE_STRUCT を定義すると、コンパイルは失敗しますが、USE_INT では成功することです。コードには、USE_STRUCT でコンパイルを成功させる方法をさらに示すコメントがあります。g++ に -fPIC オプションを指定してもコンパイルが失敗するだけですが、これは私の環境では必須の引数です。
コンパイル エラーを確認するには:
ただし、単純な int を使用しても問題ありません。
構造体の場合は val が破壊され、int の場合は破壊されない理由を説明してもらえますか? コード内のコメントに示されているように、構造体でコンパイルを成功させる他の方法についての洞察はありますか? それとも、これはコンパイラのバグを指していますか?
洞察やコメントは大歓迎です。
c - setjmp と longjmp を使用する場合の jmp_buf の実際の内容は何ですか?
setjmp() は、「リターンアドレス」と「スタックポインタ」を含むレジスタを「jmp_buf」に保存することになっています。glibc を使用して x86_64 で次のプログラムをコンパイル (gcc と clang の両方) してデバッグすると、「jmp_buf」の内容と「リターン アドレス」と「スタック ポインター」が「jmp_buf」のどこにあるのかがわかりません。
プログラムが "printf("i = %d\n", i);" の前のブレークポイントで停止した場合、gdb 機能を試しました: "p/x env"; ただし、__jmpbuf と __saved_mask を含むこの構造体 (env) に「リターン RIP」と「前の RSP」が見つかりません。これら2つの関数がどのように機能し、glibcを使用してx86_64で正確に何を保存するかを知っている人はいますか(私はubuntu 14.04を使用しています)?
c++ - C++ と、動的に生成されたコードから飛び出すための安全な方法
私のプロジェクトは C++ で書かれており、動的に生成されたコードを使用していくつかのものを結合しています (Fabrice Bellard のTCCと手動で生成されたアセンブリ サンクを少し使用しています)。動的に生成されたコードは、C++ で実装された「ランタイム ヘルパー」にジャンプして戻ってくることがあります。
どこにいても動的に生成されたコードを完全に中止して、C++ (呼び出し元) に戻ることができる機能があります。これを実現するために、単純に C++ 例外を使用しています。ランタイム ヘルパー (C 関数を装ったもの) は単純に C++ 例外をスローし、生成された関数を介して C++ に伝播します。私はSJLJを使用しており、これまでのところすべて正常に動作していますが、特定の実装に依存したくありません (SJLJ でのみ安全であると読みました)。
上記の中止スキームを除いて、私の C++ コードは主に重大な状況で例外を使用し、汎用の制御フローには使用されません。ただし、スタック上のオブジェクトを自動的に破棄するために RAII に依存しています。
私の質問は次のとおりです: setjmp が動的に生成された関数を呼び出す直前に設定され、longjmp が RAII に依存する C++ 関数を介して伝達されないことを条件として、代わりに longjmp/setjmp を使用することは理論的および実際的に安全ですか? C++ で実装されたランタイム ヘルパーはそれを利用し、常に setjmp (関数の直前に設定) に到達しますか?
または、C++ は非常に壊れやすいため、これでもうまく動作することが保証されておらず、何かが破損する可能性がありますか? それとも、実際の例外がスローされた場合にのみ C++ が壊れるのでしょうか? 例外がローカルでスローされ、すぐに (生成されたアセンブリによって呼び出されるランタイム ヘルパーで) キャッチされた場合、それは安全ですか? それとも、スタックにいくつかの外部フレームがあるという理由だけで、動作を拒否するのでしょうか?
例えば：
c - longjmp() の後に free() を呼び出す必要がありますか?
この単純なコードでは、メモリリークから逃れるためにデフォルトのケースでメモリを解放することに注意する必要がありますか、それとも割り当てられたメモリを使用できますか? longjmp もメモリ割り当てを元に戻しますか?
c - スタックの再割り当てとは何ですか? また、それはいつ行われますか?
スタックの再割り当てが発生する可能性があると述べられています。私はこれを理解していません。setjmp/longjmp の要点はスタックを保存することであり、longjmp で戻ったときに有効になると考えました。コメントは、スタック全体を移動できることを示唆しているようです。これはすべてのポインターを相殺するので、避けるべき理由がわかります。しかし、スタックの再割り当てはいつ行われるのでしょうか? この用語は今まで聞いたことがありません。