問題タブ [object-files]

基本的にobjdump -DはオブジェクトファイルとELFファイルを逆アセンブルしていました。私が見る2つの主な違いはそれです。

(個々のセグメントの) オブジェクト ファイル内の命令には、 0で始まるアドレスがあることがわかります。したがって、連続するアドレスは、おそらくその特定の命令に対応するオペコードの長さに応じて、特定の値だけオフセットされます。

一方、ELF罰金の場合、命令用の32ビットアドレス空間mainが表示されます。また、プログラムでアドレスを出力すると. これは、逆アセンブルした ELF のアドレスに相当します。

ここでの質問は次のとおりです。

• ELF ファイルのアドレスは実際には何を参照していますか?
• リンカーはそれらをどのように計算しますか?

アプリケーション自体とテスト用に 2 つの個別のプロジェクトを持つゲームがあります。すべてのプロジェクトをインソースでビルドしています。私のプロジェクト構造の短縮版は次のとおりです。

app.pro:

私の問題は、すべてのtestsプロジェクトがプロジェクトのクラスを使用しappていることです。つまり、ビルド時に既にコンパイルされていても、これらのクラスをすべてコンパイルしていますapp。layerたとえば、テスト プロジェクトを考えてみましょう。

レイヤー.プロ:

では、qmake で既に作成されている.o(およびなど) ファイルを参照するにはどうすればよいでしょうか。この目的のためのqmake変数はありますか、それとも私のプロジェクト構造に根本的な欠陥がありますか?qrc_.mocapp

私は現在、いくつかの C ソース ファイルから生成された ELF 形式のオブジェクト ファイルに取り組んでいます (私は持っていません。オブジェクト ファイルのみが利用可能です)。すべての未定義のシンボルを抽出する小さなツールを作成したときに、予約済みセクションを指すセクション インデックスを持ついくつかのシンボルに出くわしました。

詳細に：

ELF ファイルの のすべてsymbolのエントリには、シンボルが属する をSymbol Table指す整数を含むフィールドがあります。これまでのところ、これまでのところ問題ありません。範囲。後者については、ELF 仕様には非常に少ない情報しかなく、これらのセクションは次のように述べられています。section header entry index0undefined symbols0xFF00 - 0xFFFF

プロセッサ固有のセマンティクスのために予約されています。

私の質問は：

そのような を指すセクション ヘッダー テーブル インデックスを持つシンボルにつながるコードはどれreserved sectionですか? ソースコード自体からではなく、おそらくコンパイラまたは何かから来ている場合は、説明してください:)

前もって感謝します！

コードをコンパイルすると、オブジェクトファイルが生成されます。そのオブジェクトファイルから、リンクプロセスで実行可能ファイルが生成されます。

なぜオブジェクトファイルが必要なのですか？オブジェクトファイルの用途は何ですか？実行可能ファイルを直接生成することはできませんか？結局のところ、プログラムを実行するために実行可能ファイルを使用しています。

GHC でコンパイルした私のプログラムがクラッシュ*gdbし、呼び出し元の関数の名前がs10kL_info. s10kL_infoGHCにデバッグシンボルをオブジェクトファイルに書き込むことで、人間が読める関数名、または少なくとも上記の関数の人間が読める名前を表示することは可能ですか?

_{* (私のクラッシュはおそらく、外部ライブラリまたは安全でない IO 関数を使用したことが原因です)}

c ++関数を呼び出すFortran関数を含む.libライブラリファイルを作成しようとしていますが、恐ろしい「エラーLNK2019：未解決の外部シンボル...」が表示されます。コードは最終的にDLLとして他のライブラリの束でコンパイルされ、別のプログラム（PSSE）で使用されます。PSSEがライブラリを使用してDLLを作成しようとすると、コンパイルエラーが発生します。これが私が使おうとしているコードであり、その後にコンパイルコードが続きます。コードは2つの数値を足し合わせて、答えを出力する必要があります。

fort_code.f

cpp_code.cpp

compile.bat

PSSEプログラムがDLLを作成しようとすると、次のようになります。

conec / conetは、外部ライブラリ関数への単純なFortran呼び出しです。

Fortranからc++関数を呼び出すいくつかの異なる例を見てきましたが、それらはすべてわずかに異なって見えます。私が気づいたことの1つは_、c++関数名の前後で使用法が異なることでした。_CPPFUNCTION、、、またはを使用する方法を知るにはどうすればよいですCPPFUNCTIONかCPPFUNCTION_。を使用して関数をC++でエクスポートする必要があり__declspec( dllexport )ますか？ALIAS:'_CPPFUNCTION'Fortranコードでを作成する必要がありますか？

私は次のコンパイラを使用しています：ifort：IVF IA-32 v12.1.0.233 cl：v16.00.30319.01 x86

C ++コードをFortran関数に適切にリンクするために欠けているものはありますか？

mex コードと cuda コードを書いています。オブジェクトファイルを組み合わせて実行可能ファイルを取得しているため、各コードの2つのオブジェクトファイルを持ち、mexファイルからcudaカーネルを呼び出すことについて疑問に思っています。したがって、（可能であれば）あるオブジェクトファイルの関数を他のオブジェクトファイルから呼び出す方法を知る必要があります。mex と cuda を別々のコンパイラでコンパイルし、そのように結合することはできますか?

私はライブラリの操作にかなり慣れておらず、静的ライブラリとオブジェクトファイルに関するいくつかの詳細を理解しようとしているところです。

概要

私が気付いている動作は、複数のオブジェクトをリンクして実行可能ファイルを問題なく作成できることですが、それらのオブジェクトを静的ライブラリに結合する中間ステップを実行すると、それらの静的ライブラリをリンクして実行可能ファイルを作成するには、 linkコマンドにCランタイムライブラリが必要です。

また、レコードとして、コマンドラインからVisualStudio2010でコンパイル/リンクを行っています。私がフォローしているプロセスの詳細は以下のとおりです。

まず、プロジェクトに4つのソースファイルがあると しましょう：main.c、、、、。 util1.cutil2.cutil3.c

何が機能するか

1. 次のコマンドを使用して、これらのソースをコンパイルできます。その結果、、、、、および
   
   cl -c main.c util1.c util2.c util3.c
   
   の4つのオブジェクトファイルが作成さmain.objれましutil1.objた。これらのオブジェクトファイルにはそれぞれ、リンク時にこれらのオブジェクトファイル内の未解決の外部依存関係がないか静的Cランタイムライブラリlibcmt.libを追加でチェックする必要があることをリンカに通知することを目的としたDEFAULTLIBステートメントが含まれています。util2.objutil3.obj

2. これらのオブジェクトを次のコマンドでリンクすることにより、「app_objs.exe」という名前の実行可能ファイルを作成できます。
   
   link -out:app_objs.exe main.obj util1.obj util2.obj util3.obj
   
   手順1で説明したように、デフォルトのライブラリステートメントをオブジェクトに追加するコンパイラの手順により、リンカーはランタイムライブラリを使用しました。
   
   

私が混乱しているところ

1. これらのオブジェクトを静的ライブラリに結合し、結果のLIBファイルをリンクして実行可能ファイルを作成するという中間ステップが必要だとします。まず、次のコマンドを使用してこれらのライブラリを作成できます。
   
   link -lib -out:main.lib main.obj
link -lib -out:util.lib util1.obj util2.obj util3.obj

2. さて、私の当初の考えは、これらのライブラリをリンクするだけで、「何が機能するか」のステップ2で作成したものと同じ実行可能ファイルを使用できるというものでした。次のコマンドを試したところ、エントリポイントを指定する必要があることを示すリンカーエラーLNK1561が表示されました。
   
   link -out:app_libs.exe main.lib util.lib

3. Microsoftのドキュメントから、オブジェクトファイルなしでライブラリをリンクするには、エントリポイントを指定する必要があることが明らかであるため、サブシステムを「コンソール」として設定するようにコマンドを変更して、実行可能ファイルがコンソールアプリケーションであることを指定しました（特定のエントリポイントを暗示し、それによってそのエラーを解決します）：
   
   link -out:app_libs.exe -subsystem:console main.lib util.lib
   
   残念ながら、mainCRTStartupが未解決の外部シンボルであることを示すリンカーエラーが発生します。これはCランタイムライブラリで定義されていることを理解しているので、libcmt.libに対してリンクすることを手動で指定することでこの問題を解決できます。これにより、機能する実行可能ファイルが得られます。
   
   link -out:app_libs.exe -subsystem:console main.lib util.lib libcmt.lib
   
   

私が理解していないのは、コンパイラが各オブジェクトファイルに配置したデフォルトのライブラリ情報を使用してlibcmt.libへの依存関係を解決できなかった理由です。libcmt.libが必要であると明示的に指定せずにオブジェクトファイルをリンクでき、オブジェクトファイルのコンテナである静的ライブラリを作成した場合、libcmt.libが必要であると明示的に指定せずに、これらの静的ライブラリをリンクできないのはなぜですか？これはまさにその通りですか、それともリンカーがランタイムライブラリ内の未解決のシンボルをチェックすることを認識できるように静的ライブラリを作成する方法はありますか？

ご協力いただきありがとうございます。私がここで根本的に間違った考えを持っているなら、私はこれらすべてを正しく学ぶための良い参考文献に関する提案が欲しいです。

makefileを使用せずにc++ソースファイルをコンパイルできるようにしたいと思います。そして、これが私の問題のプロトタイプです...私は次の.cppファイルを持っています

.cpp同じディレクトリに、ファイルを正常にコンパイルできる次のmakefileがあります。

.cppここで、私の目的のために、このmakefileをファイルディレクトリから削除したいと思います。同時に、.cppファイルをコンパイルできるようにしたいと思います...

makefileが参照するオブジェクトファイルとライブラリがそれぞれのディレクトリにあることを知っています...。

だから、私がやりたいのは.cpp、makefileなしでファイルをコンパイルすることです。

与えられたケースに対してこのようなことをすることは可能ですか？...はいの場合、あなたの提案は本当にありがたいです！

C ++では、オブジェクトファイルを.aファイルにアーカイブする場合、プラットフォームは重要ですか？

たとえば、x64コンパイラでコンパイルしているx64プラットフォームを使用している場合、一連のCPPファイルを.oファイルにコンパイルします。AR.exeを使用して、それらを.aファイルにアーカイブし、配布します。

.aファイルはx32、x64、または互換性がありますか？または、.aファイルを使用するプログラムに依存しますか？