問題タブ [binutils]

LLVM コンパイラ ツールチェーンには、通常の gcc と互換性のある gcc があります。llvm-gcc を使用する利点は、任意のターゲットに移動することです。つまり、通常の gcc では、mips-apple-darwin などのランダムなアーキテクチャにコンパイルしようとすると、そのようなターゲットはないと通知されます。ただし、llvm-gcc は、実際には mips プロセッサ上で Mac OS X 用のコンパイラをビルドします。

ただし、問題は次のとおりです。ランダムなターゲットにビルドするには、そのターゲット用にビルドされた binutils が必要です。したがって、llvm がコンパイルできるターゲットがあり、binutils がコンパイルできない場合、GNU Binutils はそのターゲットをサポートしていないため、コンパイラを作成できません。

それで... ここに質問があります: GNU Binutils と互換性のある llvm-gcc のような同等の llvm-binutils はありますか? (リストからではなく、任意のターゲットにビルドするものを意味します。)

編集：

任意とは、llvm-gcc を実行するときにターゲットを選択しないことを意味します。llvm-gcc をコンパイルするときにターゲットを選択します。意味: mips-apple-darwin 用に GCC をコンパイルしようとすると、サポートされていないターゲットが表示されます。しかし、mips-apple-darwin 用に llvm-gcc をビルドすると、mips-apple-darwin-as と mips-apple-darwin-ld があれば動作します。

私のビルドチェーンでは、これを行う必要があります：

バイナリファイルをライブラリ形式にするため。他の人がこれを使用できるようにしたいので、ビルドを実行するときにツールチェーンから$BFDNAMEと$BFDARCHを取得する方法を知る必要があります。すでに作成したファイルに対してobjdump-fを実行することでローカルで値を取得できますが、構成値を取得するためだけに使い捨てファイルをコンパイルしたままにしない、より良い方法はありますか？

Linux では、autoconf 2.65、binutils 2.20.0。私はこのようなことをする必要があります:

おそらく -lintl への依存が原因で、2 番目のチェックが失敗しました。

ここで誰かがそれを修正する方法を教えてもらえますか? どうもありがとう！

割れ目

Linux2.6.32.2カーネルを実行しているSamsungS3C2440SoC（ARM920Tコアに基づく）用のCプログラムをコンパイルしたいと思います。ARM926EJSで実行されている既存のGentooLinuxインストールがあります。

次のgccオプションを使用して、S3C2440用のCプログラムをコンパイルします。

コンパイルされた実行可能ファイル（単一のprintf "hello world"）を実行すると、単に「IllegalInstruction」が表示されます。ターゲット用にコンパイルされたGDBがなく、dmesgが障害のある命令のアドレスを報告しません。

実行可能ファイルで「objdump-d」を実行すると、ARM920Tコアでは明らかにサポートされていないBLX命令がリストされていることがわかります。

さらに調査すると、BLXはGNU-EABIバイナリでのThumbサポートに使用され、「ld」によって生成されるようです。オブジェクトファイルのみのobjdump-d出力にはBLX命令が含まれていないため、GCCの「-c」オプションを使用してコンパイルするだけでこれを確認できるようです。

BLX命令は私が抱えている問題でしょうか？もしそうなら、最終的にリンクされた実行可能ファイルでBLX命令を生成しないように「ld」に指示するにはどうすればよいですか？

ソフトウェアバージョン：

いくつかの追加のロギングコードを静的にリンクされた（android arm linux）実行可能ファイルにマージしようとしています。

（通常のトレースメソッドは機能していないようです。これは、何か面白いことをする直前にclone（）を実行するデーモンプロセスであるためです。straceにこれに従うように指示すると、クラッシュするだけです）。

ジャンプ命令を新しいコードに挿入するために既存のコードを16進数で編集することはテストされ、機能しています。問題は、既存のセグメントに干渉しないように新しいコードを実行可能ファイルにマージし、にロードされることです。実行可能ページ。

すべての追加コードを単一のオブジェクトファイルセクションに凝縮することはできましたが、objcopy（またはld）を使用して、適切にロードされるようにマージする方法を理解できません-私はそうです既存のロードセグメントのサイズを変更して移動するか、尊重されるセグメントを追加する必要があります。

すでにリンクされ、現在静的な実行可能ファイルに必要なスタブを追加する方法がある場合は、共有ライブラリにコードを追加することもできます（次に、スタブの既知の場所にジャンプ命令で16進編集します。これは、ランタイムです。その後、リンカーは追加されたコードをポイントします）

この-lオプションは、リンカーに標準ディレクトリ内のライブラリを検索するように指示します。を使用すると-L、検索用に独自のライブラリ ディレクトリを指定できます。

質問: 順序の順序は、リンカーの wrt の-L場合と同様に、オプションでも重要ですか?-l

このリンク: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.htmlは、 のシーケンスについてあまり述べていません-L。

編集 また、

コマンド ラインで指定されたディレクトリは、デフォルト ディレクトリの前に検索されます。

マニュアルページからのものです（ドミトリーが指摘したように）、これは、次のように順序を指定しても、ということですか。

で指定されたディレクトリ-Lが優先されますか?

Fedora を mips cpu に移植しようとしています。「sudo」「krb5」などのパッケージがあります。以下は、「-fpie」「-pie」フラグが自動追加された configure によって生成された「sudo」の Makefile です。

sudo を実行しようとすると、コアダンプが発生します。gdb --core core.8420 のコール フレーム:

-pie ld フラグを削除すると、すべて問題ありません。これは、binutils または glibc ライブラリ ローダーが原因ですか?

私は、ローカル マシン上で動作する gcc クロス コンパイラを作成しようとしています [Darwin new-host-2.home 10.7.4 Darwin Kernel Version 10.7.4: Mon Apr 18 21:24:17 PDT 2011; root:xnu-1504.14.12~3/RELEASE_X86_64 x86_64] であり、FreeBSD 8.2 x86_64 (FreeBSD 用語では AMD64) ターゲットを対象としています。

gcc 4.3.1、binutils 2.19、GMP 4.2.3、MPFR 2.3.2 をコンパイルしています。

問題が発生している可能性があることがいくつか見られますが、それらはニシンである可能性があります。価値があるのは、既知の作業スクリプトを使用してクロス コンパイラを構築し、単純にそれらを x86_64 アーキテクチャで動作させようとしているからです。

gcc コンパイラ ターゲット "x86_64-pc-freebsd7" を使用していますが、これは正しいようです。次のコンパイラ フラグを使用し、次compilerConfigureFlags="--enable-version-specific-runtime-libs --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit"を使用して binutils を構成します。"--enable-64-bit-bfd"

私の最後のエラーで。私の注意を引くのは「-m32」で、そこにあるべきかどうかわかりません。エラーは、-lc を検索するときに、「互換性のない」ファイル /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.a をld が理解できないためです。. fileFreeBSD ボックスから libc.a と libc.soを実行すると、次のようになります。

sh-3.2# ファイル /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.a/Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/ x86_64-pc-freebsd7/lib/libc.a: 現在の ar アーカイブ

sh-3.2# ファイル /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/libc.so /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/ x86_64-pc-freebsd7/lib/libc.so: ELF 64 ビット LSB 共有オブジェクト、x86-64、バージョン 1 (FreeBSD)、動的にリンク、ストリップ

私のビルドが死ぬ最終行：

o _floatundidf_s.o _floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-c_s.o emutls_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; 次に mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; そうでなければ真。fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/ x86_64-pc-freebsd7/bin/ld: -lc /Developer/Cocotron の検索時に、互換性のない /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib//libc.so をスキップします/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: 非互換スキップ /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/lib/ libc.

このバージョンの「ld」を実行すると、次の出力が得られるため、ld が処理できないことに驚いています。

/Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: サポート対象: elf64-x86-64-freebsd elf32-i386-freebsd coff-i386 efi-app-ia32 efi-bsdrv-ia32 efi-rtdrv-ia32 efi-app-x86_64 efi-bsdrv-x86_64 efi-rtdrv-x86_64 elf32-i386 elf64-x86-64 elf64-little elf64-big elf32-little elf32-big srec シンボルrec tekhex バイナリ ihex /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1/x86_64-pc-freebsd7/bin/ld: サポートされているエミュレーション: elf_x86_64_fbsd elf_i386_fbsd elf_x86_64 elf_i386 /Developer/Cocotron/1.0/FreeBSD/x86_64/gcc-4.3.1 /x86_64-pc-freebsd7/bin/ld: エミュレーション固有のオプション: elf_x86_64_fbsd:

これは、binutils を正しくビルドしたことを示しています..それでも、ELF 64 ビット x86-64 FreeBSD 共有オブジェクトであるライブラリを処理できませんか??

最初から話をすると、binutils のコンパイルは完璧なようです。

GMP と MPFR の両方をコンパイルすると、ranlib の問題が発生し、.a ライブラリを構築しようとすると、.o ファイルにシンボルがありません..これは正常かもしれませんが、わかりませんか?

GMP:

/blockquote>

そして、私はさらに先に進みます..

/blockquote>

MPFR:

同様の取引:

p>

そして、もう少し先..

p>

次に、GCC に進みます。おそらく、適切な binutils、GMP、および MPFR を使用します。しかし、最終的に gcc (具体的には libgcc) のビルド中に、ld リンク エラーが発生します。

---

その他の補足情報:

以下を使用して binutils をコンパイルします。

p>

ただし、-m64 に切り替えると、同じ問題が発生します。

p>

以下を使用して GMP と MPFR をコンパイルします。

p>

以下を使用して GCC をコンパイルします。

p>

これらすべてについて、私は以下を使用しています：

---

ちなみに、標準の FreeBSD 8.2 RELEASE amd64 である私のターゲット FreeBSD システムでは、ld は私のクロスコンパイルのものと非常によく似た機能を示します。実際、私のクロスコンパイル環境の ld は、実際のターゲットの ld が処理するもののスーパーセットを処理しているようです - 私が見ている非互換性なしで、どんなファイルも処理できるはずだと思います

p>

私はその一部です ( http://www.linuxfromscratch.org/lfs/view/6.6/chapter05/binutils-pass2.html ) ( http://www.linuxfromscratch.org/lfs/view/6.6/chapter05/binutils -pass1.html )

binutils をもう一度ビルドするように言われますか? 最初に使用した binutils-build ディレクトリを削除して、このビルド用に新しいディレクトリを作成する必要があるかどうかわかりませんか??? パス 1 とパス 2 とは何ですか? 私は混乱しています ：/

助けてください ：）

デバッグをオンにして binutils 2.21 ソース コードをビルドしようとしています。私の主な目的は、実際に objdump をデバッグすることです。しかし、それをビルドするには、パッケージ全体をビルドする必要があると思います。

残念ながら、構成ファイルにはデバッグ オプションがありません。設定する前に -g と -ggdb を CFLAGS に追加してみました。ただし、エラーは次のとおりです。

「make clean」と「make distclean」を試しましたが、同じエラーが発生します。実際、以前の CFLAGS によると、以前は -g オプションがオンになっていましたが、gdb で objdump.exe を開こうとすると、

前もって感謝します。