問題タブ [objcopy]

ARM Cortex A8 を使用するプロジェクトで、ARM Cortex M4 用にプリコンパイルされたライブラリを使用する必要があります。リンカーは自然にエラーを出します：

file "..." has a Tag_CPU_arch_profile attribute value of "77" that is different than one previously seen ("65"); combining incompatible files

arm-none-eabi-objcopy を使用してライブラリを変換できますか? 周辺機器やマイクロコントローラ自体に固有のコードは含まれていません。どちらもアームです。可能性が高いようですが、どうですか？

intel hex records type 03 または 05 は iHex プログラムで何をしていますか?

レコード タイプ03: 開始セグメント アドレス80x86プロセッサの 場合、CS:IP レジスタの初期内容を指定します。アドレス フィールドは 0000、バイト カウントは 04、最初の 2 バイトは CS 値、後の 2 バイトは IP 値です。

レコード タイプ05: 開始線形アドレスアドレス フィールドは 0000 (未使用) で、バイト カウントは 04 です。4 つのデータ バイトは、 80386 以降のCPU の EIP レジスタにロードされる 32 ビット値を表します。

これらはARMプログラムにとって意味がありますか?

組み込み ARM をプログラムするために .hex を生成すると、エンディングは次のようになります。

:10851400B4040020BC040020BC040020C4040020D7
:10852400C4040020CC040020CC040020D404002087
:10853400D4040020DC040020DC040020E404002037
:10854400E4040020EC040020EC040020F4040020E7
:10855400F4040020FC040020FC040020FFFFFFFFC3
:048564000000020011
:040000 05 08002910B6
:00000001FF

このレコードを無視するようにプログラミング アプリを編集しましたが、ちょうど今日、同僚が、彼のコンパイラが最後から 2 番目の行で03タイプのレコードを生成し、MPU のプログラミングを妨げていると報告しました。

objcopy がこれらのレコードを作成するのはなぜですか? それをやめさせることはできますか？

関連する Makefile 行:

gccを使用してフラットバイナリファイルを作成しようとしていますobjcopy。私のCコードは次のようになります：

バイナリを作成するとき

コード セクション ( .text) は正しくリンクされていますが、データ セクション ( .rdata) はコード セクションの後ろに配置されているだけで、コード セクションとリンクされていません。データ セクションの何かにアクセスすると、正しい場所からではなく 0x0x401000 から何かが読み込まれ、クラッシュします。

これを解決する方法はありますか？

PS: 動作する C コードは次のとおりです。

objcopy を使用して、リソース ファイル (zip ファイル) をフラッシュ メモリ (ARM に埋め込まれたもの) に埋め込むために必要なスクリプトを削除しています。

私は次のようにobjcopyを使用しています：

私が知る必要があるのは、_end および _size シンボルの幅です。_start は、バイト配列のようにアクセスできるアドレスであると推測できます: extern uint8_t _binary_input_zip_start[];. そして、_end と _size は「ネイティブ」の int サイズであると想定しています。これらを uint32_t として解釈できると安全に想定できると思います。

しかし、私は確信が持てません。objcopy のドキュメントに関連する「サイズ」が見つかりません: https://sourceware.org/binutils/docs/binutils/objcopy.html

コードを生のバイナリにコンパイルしようとしていますが、他の SO 投稿 ( thisやthisなど) で示唆されているように、objdump を試しました:

次に、これが有効かどうかを確認しようとしました:

明らかに何かが間違っています。これを gcc クロスコンパイルの結果で確認しましたが、明らかに正しくない結果がほとんど同じでした。

ストリップされたバイナリから Linux でブレークパッド シンボルを生成するのに苦労しています。

私はコンパイルします：

いくつかの C++ ファイルもあります。

私は次にリンクします：

最後に、デバッグ情報を次のように .debug ファイルに取り除きます。

結果のバイナリは、完全なシンボル情報を使用して GDB でデバッグできます。（ディレクトリパスなし）.gnu_debuglinkを参照するセクションが含まれていますが、これは正しいです。foo.so.debug

ただし、このパッチで編集されているコードは、リンクをたどる必要があることを強く示唆していますが、dump_syms はリンクをたどっていないようです。この出力を stderr に取得します。

.gnu_debuglink結果のシンボル ファイルは、セクションが ELF に存在するかどうかに関係なく、2MBです。この 2MB のシンボル ファイルを minidump_stackwalk で使用すると、スタック フレームに間違った関数が表示されます。シンボルが埋め込まれたバイナリで実行するdump_symsと、出力ファイルは 9MB になり、スタック フレームは正しくなります。

私は何を間違っていますか？

g++ バージョン 2.96 を使用してビルドされたライブラリ ファイルがあります。lib のソース コードは入手できず、元の開発者からのサポートもありません。

最新の g++ バージョン (4.x など) を使用してアプリケーションにリンクしたいと考えています。私が理解しているように、gcc veriosn 3.3 以降、名前マングリング スキームが変更されました。そのため、新しいリンカーは古い lib ファイルのシンボルを認識しません。

私はネットでいくつかの調査を行い、objcopy、objdump、c++filt、nm などのツールを調査し、lib ファイル内のシンボルを手動で見つけてデマングルしようとしましたが、役に立ちませんでした。

それで、新しいコンパイラを使用してリンクできるように、古いバイナリ lib ファイルを新しい名前マングリング スキームに変換する方法 (またはツール) はありますか?