問題タブ [alloca]

x86 Linux システムでスタック オーバーフローを引き起こす特定の条件があります。

• struct my_big_object[HUGE_NUMBER]スタック上。それを歩くと、最終的に が発生しSIGSEGVます。
• alloca()ルーチン ( と同様ですが、malloc()スタックを使用し、自動的にそれ自体を解放し、SIGSEGV大きすぎる場合は爆発します)。更新: 最初に述べたように、 alloca() は正式に廃止されたわけではありません。それはただ落胆するだけです。

特定のオブジェクトに対してローカル スタックが十分に大きいかどうかをプログラムで検出する方法はありますか? を介してスタックサイズを調整できることを知っているulimitので、方法があることを願っています（ただし、移植性はありません）。理想的には、次のようなことができるようになりたいです。

D、C、C++ などの言語でインライン x86 アセンブラーを使用して alloca() を実装するにはどうすればよいですか? 少し変更したバージョンを作成したいのですが、まず、標準バージョンがどのように実装されているかを知る必要があります。コンパイラは非常に多くの最適化を実行するため、コンパイラから逆アセンブリを読み取ることは役に立ちません。正規の形式が必要なだけです。

編集:難しい部分は、これに通常の関数呼び出し構文を持たせたいことだと思います。つまり、ネイキッド関数または何かを使用して、通常の alloca() のように見せます。

編集 # 2: ああ、なんと、フレ​​ーム ポインターを省略していないと推測できます。

alloca()の場合のように、ヒープではなくスタックにメモリを割り当てますmalloc()。したがって、ルーチンから戻ると、メモリが解放されます。したがって、実際には、これにより、動的に割り当てられたメモリを解放するという私の問題が解決されます。割り当てられmalloc()たメモリの解放は大きな頭痛の種であり、何らかの理由で見落とされた場合、あらゆる種類のメモリの問題が発生します。

上記の機能にもかかわらず、なぜ使用がalloca()推奨されないのですか？

私はスマート ポインター型を持っており、その型のポインターと (実行時に動的に計算される) カウントを受け取り、スマート ポインターが指すオブジェクトの多くのインスタンスを保持するのに十分なメモリをスタックから割り当てるオブジェクトを構築したいと考えています。 . これを達成するための正しい構文が見つからないようです。出来ますか？

このようなものを考えると

私はこのようなことをしたい:

次のマクロを呼び出すコードはコンパイルされません。これは、コンパイラが _wrappedPtr から SomeObject のテンプレート パラメーターを推測できないため、テンプレート パラメーターが欠落していると不平を言うためです。

ポインター ラッパー型でテンプレート化された関数が使用されている場合、コンパイラは型を暗黙的に推測できますが、それを呼び出すコードはコンパイルされません。これは、SomeObject がコピー コンストラクターまたは代入演算子を意図的に定義しますが、実装しないためです。alloca() によって提供されたメモリがすぐに範囲外になるため、コンパイルしたとしても正しいことをしません。

実際のコードでは、使用時に非常に長くて読みにくいステートメントになるため、型を引数としてマクロに渡すことは避けたいと思います。可能。

最近、llvm-gcc によって作成された LLVM アセンブリを調べていて、その目的がよくわからないステートメントが繰り返し表示されていることに気付きました。

たとえば、次の C プログラム:

「llvm-gcc -emit-llvm -S」でコンパイルすると、次のコードが生成されます (無関係な部分は削除されています)。

行の目的に興味があります:

割り当て先の変数は二度と使用されず、ビットキャスト自体は無意味であるため、何もしないようです。私が考えることができるのは、後でコード生成/分析の目的で実際に nop として挿入され、コードの興味深い部分を示しているということだけです。

GCが有効になっているObjectiveCプロジェクトでは、次のようにスタックに可変サイズの配列を割り当てています。

（これを実行する理由は重要ではありません:)次に、ループ内で、myStackにデータをプッシュおよびポップします。私がスタックにプッシュするもののいくつかは、他のどこからも参照されていない新しいオブジェクトです。

私の直感は、Objective Cのガベージコレクターがそれらのポインターについて知らないため、新しい（そうでなければ参照されていない）オブジェクトを収集することを示しています。その信念の一部は、Objective C GCは実際には保守的ではなく、「そのポインタを知っている」（たとえば、スタックマップを通じて）という考えに由来しています。

ただし、すべての実験（[[NSGarbageCollector defaultCollector] collectExhaustively]呼び出しを挿入）では、これらのオブジェクトを収集できませんでした。これは良いことですが、予期しないことです。したがって、GCはスタック全体をスキャンしているようであり、たとえば、有効なポインターの値を持つ整数が実際にはポインターであると控えめに想定しています。

あれは正しいですか？それとも私は何かが足りないのですか？

allocaはC++標準の一部ですか？

何らかの理由で、gccを使用してCファイルをコンパイルしてから、Visual C++2008プロジェクトにリンクする必要があります。

（私は現在の最新のgccバージョン：cygwin gcc 4.3.4 20090804を使用しました。）

ただし、問題が1つあります。gccは常に_allocaを使用して大きな配列を割り当てます。

また、VCリンカーはシンボル__allocaを解決できません。

例えば、

このコードは、_alloca関数を明示的に呼び出さなかったにもかかわらず、_alloca依存関係を作成します。

（配列サイズが重要です。10240-> 128を変更した場合、すべて問題ありません）

gccオプション-fno-builtin-allocaまたは-fno-builtinを試しましたが、うまくいきませんでした。

gccに_allocaを使用しないようにすることは可能ですか？（またはしきい値を調整しますか？）

違いは何ですか

と

...ここで、サイズはコンパイル時に値が不明な変数です。