問題タブ [il]

VS プラグインまたはスタンドアロン アプリケーションの形式の IL レベルのデバッガーはありますか?

Visual Studio のデバッガーは優れていますが、HLL コード レベルまたはアセンブリ言語のいずれかでデバッグできます。IL をデバッグすることはできません。状況によっては、IL レベルでデバッグする機会があると便利なようです。

特に、ソースがないコードの問題をデバッグする場合に役立つ場合があります。

ソースがないときに IL をデバッグすることが実際に役立つかどうかは議論の余地がありますが、とにかく。

私は、JVM バイトコード (ASM、cglib、jad など) を操作、生成、逆コンパイルするための Java ツールについてよく知っています。CLR バイトコード用の同様のツールはありますか? 人々は CLR のバイトコード操作を行いますか?

Joel Spolsky と Jeff Atwood がポッドキャストで、業界や配信プラットフォームに関係なく、プログラマーが C を学ぶべきかどうかについて意見の相違を始めたとき、開発者コミュニティ内で非常に爆発的な議論が巻き起こりました。私は、多くのプログラマーブロガーから、この問題についての彼らの意見を読んでいます。双方の主張には確かに重みがありますが、私が見つけられなかったのは、.NET Framework のみに焦点を当てた開発者の観点から独自の角度から見た視点です。ほぼ全員が、一般的なプログラマーの観点からコメントしていました。

私は何を手に入れようとしていますか？このような高レベルの開発者が費やす時間のほとんどは、ビジネス/ドメインの学習に費やされ、それらのドメイン要件を達成するためのテクノロジを学習するために必要なすべての時間に費やされるという Jeff Atwood の意見を思い出してください。私の実務経験では、多くの人の仕事生活を非常に正確に説明しています。.NET 開発者が「課外」学習の時間を分岐できると仮定すると、それは Cである必要がありますか?

記録として、私は学校で C を学んでおり、支持者が何を理由にしているのかを完全に理解し、評価することができます。しかし、よく考えてみると、個人的には、.NET 開発者は C に直接飛び込むべきではないと感じています。なぜなら、より多くの開発者に時間をかけて習得してもらいたいのは、MSILとCLRです。

たぶん、私は異常な同僚の集まりに行き詰まっているのかもしれませんが、私にはわかりませんが、多くの人は、JIT が導入されて生のマシンになる前に、C# または VB コードが最初に IL でコンパイルされることを意識していないようです。コード。ほとんどの人は IL を知らず、作成したコードを CLR がどのように正確に処理するかに関心がありません。Jeffrey Richter のCLR を C# 経由で読んだことは、私にとって非常に多くの分野で衝撃的でした。同僚が「レベルが低すぎる」と却下したにもかかわらず、読んでよかったです。私は IL の専門家ではありませんが、基本的な知識があれば、IL のスタック動作にすでに精通していたので、彼のテキストに従うのがより簡単であることに気付きました。特定のコードを記述したときに IL がどのようになるかを確認するために、アセンブリを逆アセンブルしていることに気づきました。

CLR と MSIL を学習するのは、それが自分の直下の層であることを知っているからです。自分の作業のレイヤーを実行できるようにするレイヤー。C、実際にはさらに下にあります。私たちの「現実」に近いのは、CLR と MSIL です。そういうわけで、私は他の人にそれらを試してみることをお勧めします. それとも、あなたのチームはすでに MSIL に精通していますか?

.NETアセンブリ用の静的分析ツールに取り組んでいます。Javaには、指定された文法で文字列内のメソッドまたはフィールドを表すために使用できる記述子があります。

フィールドの場合：

double d[][][];

になります

[[[D

これは、バイトコード分析を行うときに特に役立ちます。Cozそれは説明するのは簡単です。.NET CLRに同様のものがある場合はどうなりますか？それとも、これを達成するためのより良い方法はありますか？ありがとう！

関数の実行中に現在のスタックへのポインターを設定し (後で取得する)、現在のスレッドを解放し (コール スタックをアンワインドせずに)、それをスレッド プールに戻すことはまったく可能ですか? そして、そのスレッドが中断したところから別のスレッドを取り上げますか? 関数を呼び出す人が現在のスレッド コンテキストが変更されたことを知らないことを意味することはわかっています。おそらく、このようなことを行うためにカスタム IL コードを記述する必要がありますが、これを行う方法はありますか?

Windbg (sos エクステンション付き) を使用しており、クラッシュしたアプリケーションをデバッグしようとしています。例外をスローした呼び出しの IL をダンプすることができ、コードを調べると、評価スタックの内容をダンプできれば必要な情報を取得できたようです。WinDbg & sos で何ができますか?

これが私がしたことです：

1. WinDbgを開始しました
2. クラッシュしたプロセスに接続
3. loadby sos mscorwks (sos 拡張機能をロードするため)

4. !token2ee theModuleName 0600009a (ここで、theModuleNameはデバッグ中のアプリ (およびアセンブリ) の名前で、9aは Windows エラー報告ツールによって報告されたクラッシュしたメソッドのメソッド オフセットです。次の出力が得られました。

   モジュール: 000e2c3c (theApplicationName.exe)
   トークン: 0x0600009a
   MethodDesc: 000e67c8
   名前: MyNamespace.MyClassName.theCulpritFn(MyOtherClass)
   JITTED コード アドレス: 0081b1d0
   

5. !dumpil 00e67c8 (問題のメソッドの IL をダンプした) . これは出力です：

   問題は、例外がスローされる前に何がスタックにプッシュされたかを確認する方法があるかどうかです。私が間違っていなければ、例外コンストラクターに渡される引数は、評価スタックのインデックス 0 にあるローカル変数でなければなりません。

   PS !clrstack -aを呼び出そうとすると、次のメッセージが表示されました。現在のスレッドはマネージド スレッドではない可能性があります。!threads を実行して、プロセス内のマネージド スレッドの一覧を取得できます。

ありがとう！

インターフェイスを取り込んで、.GetEvents() 戻り配列をループし、動的型にイベントを実装しようとしています。TypeBuilder.CreateType() を呼び出そうとすると、次の素敵なエラーが表示されます。

「アセンブリからの型のアプリケーション メソッドは、オーバーライドされたメソッドをオーバーライドしています。」

インターフェイス メソッドを実装しようとする typeBuilder.DefineMethodOverride 呼び出しをコメント アウトすると、イベントをサブスクライブしようとした時点でエラーが発生します。

「メソッドまたは操作が実装されていません。」

これは、検出されたイベントを発行されたタイプに追加しようとしている方法です。ちょっとしたメモですが、型を定義し、それらをインターフェイスに実装するメソッドを追加する他のコードがあり、そのコードはすべて正常に機能します。イベントをミックスに追加しようとするまで、問題はありませんでした。

Google はこれについて何の助けもありません (「オーバーライドされたメソッドをオーバーライドしています」を検索すると、多くの Crystal Reports トピックが返されます)、私は午前中ずっとこれに苦労してきました。どんな助けでも大歓迎です！

なぜこれが起こっているのか知りたいです。以下のコード例と、各セクションの下のコメントで発行された対応する IL をお読みください。

コンパイラがcallvirt最初のセクションではを出力callし、2 番目のセクションでは を出力したのはなぜですか? callvirtコンパイラが非仮想メソッドの命令を発行する理由はありますか? また、コンパイラがcallvirt非仮想メソッドに対して a を発行する場合がある場合、これは型安全性の問題を引き起こしますか?

いくつかの特別なメソッドがあり、コンパイルされたアセンブリで呼び出しを分析したい。

例：

このコンパイルされたコードから、引数の値を取得したい {「指定されたサイズの「、MyClass、」の配列を作成する必要があります。」}。Mono から Cecil を使ってみたところ、"ToDo" メソッドを呼び出すための手順が見つかりました。しかし、引数値で命令を識別する方法がわかりません。

複雑な状況が発生する可能性があり、一部の引数の値を解決できないことはわかっています。しかし、定数値のみを解決する必要があります-私の目的には十分です。

ありがとう。

編集: 「ToDo」メソッド (および同様のもの) は、コメント ( //、/* ... */ ) の代わりに使用する必要があり、コンパイル後に IL を分析し、具体的なアセンブリのドキュメントと todo リストを自動生成する必要があります。 .

私は .NET については多少初心者ですが、プログラミングについては初心者ではありません。また、コンパイル済みの .NET コードを逆アセンブルすることについての傾向と興奮にやや戸惑っています。無意味に思えます。

.NET の高度な使いやすさが、私が .NET を使用する理由です。リソースが限られている環境で、C および実際の (ハードウェア プロセッサ) アセンブリを作成しました。それが、効率のために非常に多くの細心の注意を払うことに労力を費やす理由でした. .NET の世界では、実装の最も不可解な詳細を掘り下げて時間を無駄にすると、高レベルのオブジェクト指向言語を使用するという目的が無効になります。.NET を使用する過程で、通常のパフォーマンスの問題と奇妙な競合状態をデバッグしました。コンパイラが生成している中間言語について考えたことは一度もありませんでした。たとえば、 foreach() が列挙型を使用することを考えると、 for(;;) ループが配列の foreach() よりも高速になることは明らかです。変数を単純にインクリメントするのではなく、次に進むたびにメソッド呼び出しを使用してオブジェクトを作成します。これは、タイトなループを数百万回実行することで簡単に証明できます (逆アセンブルは不要です)。

IL の逆アセンブルを馬鹿げているのは、実際のマシン コードではないという事実です。仮想マシンコードです。実際に命令を移動して最適化するのが好きな人もいると聞きました。私をからかってるの？ジャストインタイムでコンパイルされた仮想マシン コードは、ネイティブにコンパイルされたコードの速度では単純なタイトな for(;;) ループを実行することさえできません。プロセッサから最後のサイクルをすべて絞り出したい場合は、C/C++ を使用して、実際のアセンブリの学習に時間を費やしてください。そうすれば、多くの低レベルの詳細を理解するのに費やす時間は、実際には価値があります。

では、時間に追われる以外に、人々はなぜ .NET (CLR) バイナリを逆アセンブルするのでしょうか?