こんにちは、KATA_KANと申します。こちらで聞くのが適切かどうかわかりませんが、e2studioを使用している為、こちらに書き込みさせて頂きました。
前任者より引継ぎを受けた、e2studioのプロジェクト(ARM CPU搭載オリジナルボード用)をそのままビルドしたところ、生成されたバイナリが前任者が作成したものと大きく異なり（比較するとタイムスタンプ以外に差分が多数）、また、生成されたバイナリをボードに書き込んでも、動作しないという状況に陥りました。
使用するGCC Arm EmbeddedのToolchainのバージョンなども前任者と合わせているはずなのですが、何故、ビルドしたバイナリに大きな差分が出るのかがわかりません。また、バイナリに差分があることよりは、生成されたバイナリでボードが動作しないことが問題と考えています。
別環境で作られたe2studioプロジェクトをローカルに持ち込んでビルドした際、バイナリに大きな差分が発生する要因に関してご助言を頂けますと幸いです。
GCC Arm Embeddedのバージョンは、前任者、私共に10.3.1.20210621e2studioのバージョンは前任者は2023/1、私は2023/7を使用しています。他、必要な情報があれば、適宜要求頂けましたら展開いたします。
何卒宜しくお願い致します。
どこぞのARM系向けビルドのため、e2studioをeclipse CDTの代わりに使われているということでしょうか？差分というのはバイナリのサイズが大きく違うという意味で書いてあるのでしょうか？それともELFファイルの中身を比較されているということでしょうか？ビルド構成が違ってるということはないですか？それによって最適化オプションやビルドのマクロ定義などが異なっている場合、ソースコードの書き方によっては動作が思っている状態にならない場合があります。
>Yamamoto様返信ありがとうございます。
>どこぞのARM系向けビルドのため、e2studioをeclipse CDTの代わりに使われているということでしょうか？RZ向けの構成を入れてインストールしたものを該当ボード用にカスタムしたような記載が前任者からの資料にありましたので、そういうことかと推測しております。
>差分というのはバイナリのサイズが大きく違うという意味で書いてあるのでしょうか？それともELFファイルの中身を比較されているということでしょうか？差分はWinMergeで確認しています。ビルドを行うと、mapファイル、outファイル、binファイルが出力され、その中のoutファイル、binファイルに大きな差分が出ております。outファイルはサイズ自体も大きく異なり、前任者が作成したものは4M程度になるのに対し、私の環境で作成したものは1.5M程度になっております。binファイルはサイズ自体は前任者が1.314Mの私の環境が1.3Mジャストとあまり差がないのですが、中身をWinMergeで差分を比較すると、殆どの箇所で差分が生じているような状態となります。
>ビルド構成が違ってるということはないですか？それによって最適化オプションやビルドのマクロ定義などが異なっている場合、ソースコードの書き方によっては動作が思っている状態にならない場合があります。プロジェクト内に「.cproject」というファイルがあり、最適化オプションの設定などを変更すると、そのファイルが更新されるということが確認出来ております。現時点では、「.cproject」ファイルの内容が変更されないようにビルドを行っている為、設定値は同じものが使用出来ていると認識です。
ここで言う out ファイルとは何でしょう？ロードモジュールであれば拡張子のデフォルトがGCCだと*.elfなので何だろうと思いました。(IARだと*.outです)普通にプロジェクトをインポートしたのであれば、.cproject ファイルはそのままコピーされるだけなのでビルドオプションは変わらないはずです。何か手を加えているのではないでしょうか？(参考) FAQ - e² studioへのプロジェクトのインポートhttps://ja-support.renesas.com/knowledgeBase/21062026
>ほやさん返信ありがとうございます。
>ここで言う out ファイルとは何でしょう？>ロードモジュールであれば拡張子のデフォルトがGCCだと*.elfなので何だろうと思いました。(IARだと*.outです)ビルドを実行した際のコマンド履歴を提示させて頂きます（ソースコード名、オリジナルライブラリ名などは伏せております）
arm-none-eabi-gcc -mcpu=cortex-a5 -marm -mthumb-interwork -mlittle-endian -mfloat-abi=softfp -mfpu=neon-vfpv4 -munaligned-access -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections [ビルド対象ソースコードの指定] ・ ・ ・(中略) ・ ・ ・arm-none-eabi-gcc -mcpu=cortex-a5 -marm -mthumb-interwork -mlittle-endian -mfloat-abi=softfp -mfpu=neon-vfpv4 -munaligned-access -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections [ビルド対象ソースコードの指定]arm-none-eabi-gcc -T "..\\\\XXXXXXX.ld" -nostartfiles -Xlinker --gc-sections -L ../../../libs -Wl,-Map,XXXXXXX.map --specs=rdimon.specs -Wl,--start-group -lgcc -lc -lrdimon -Wl,--end-group -o XXXXXXX.out [*.oファイルの一覧×複数] -l[オリジナルlib×複数] -lc -lm arm-none-eabi-size --format=berkeley XXXXXXX.out text data bss dec hex filename1109196 221523 132425768 133756487 7f8f647 XXXXXXX.outarm-none-eabi-objcopy -O binary XXXXXXX.out XXXXXXX.bin
outファイルは、arm-none-eabi-gccを実行した際に作られる*.oファイルやlibファイルを結合したファイルである認識です。最終的にarm-none-eabi-objcopyを実行し、outファイルをbinファイルに変換しているようです。
>普通にプロジェクトをインポートしたのであれば、.cproject ファイルはそのままコピーされるだけなので>ビルドオプションは変わらないはずです。>何か手を加えているのではないでしょうか？プロジェクトはSVNにアップロードされたものをチェックアウトし、そのプロジェクトを提示頂いた手法と同じ手法でe2studioにインポートしております。
インポート前後で「.cproject」ファイルに差分は生じていなかった為、ビルドオプションは変更されていないという認識でおります。
*.outはロードモジュールの拡張子でしたか。toolchainのバージョンもビルドオプションも変わらないのにサイズが違うとは不可解ですね。どこのサイズが違うのか、objdumpで確認してみてはいかが。(参考) FAQ - GCCプロジェクトでセクションの配置アドレス範囲を確認する方法https://ja-support.renesas.com/knowledgeBase/20792140元のプロジェクトとmapファイルを比較すればリンク対象のファイルに違いがないかも確認できます。
>ほやさん頂いた情報に基づき、objdumpを実行してみました。
●前任者outファイル
Sections:Idx Name Size VMA LMA File off Algn 0 .vectors 00000058 80000000 80000000 00010000 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 00106b80 80000060 80000060 00010060 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 0000b914 80106be0 80106be0 00116be0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .ARM.extab 00000030 801124f4 801124f4 001224f4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .ARM.exidx 000000f0 80112524 80112524 00122524 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .data 0003615c 80112618 80112618 00122618 2**3 CONTENTS, ALLOC, LOAD, DATA 6 .bss 00080f48 80148778 80148778 00158774 2**3 ALLOC 7 .system 001c1108 801c96c0 801c96c0 00158774 2**2 ALLOC 8 .sdram 04000000 c0000000 c0000000 00160000 2**2 ALLOC 9 .vram 03bf0000 80400000 80400000 00160000 2**2 ALLOC 10 .mram 00010000 83ff0000 83ff0000 00160000 2**2 ALLOC 11 .stack 00008000 fe000000 fe000000 00160000 2**0 ALLOC 12 .debug_aranges 000054e8 00000000 00000000 00158774 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 13 .debug_info 0013efbc 00000000 00000000 0015dc5c 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 14 .debug_abbrev 0001b5c0 00000000 00000000 0029cc18 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 15 .debug_line 00089651 00000000 00000000 002b81d8 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 16 .debug_frame 00013d7c 00000000 00000000 0034182c 2**2 CONTENTS, READONLY, DEBUGGING, OCTETS 17 .debug_str 00023994 00000000 00000000 003555a8 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 18 .debug_loc 000da10c 00000000 00000000 00378f3c 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 19 .debug_ranges 00017c60 00000000 00000000 00453048 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 20 .comment 0000005e 00000000 00000000 0046aca8 2**0 CONTENTS, READONLY 21 .ARM.attributes 00000037 00000000 00000000 0046ad06 2**0 CONTENTS, READONLY
●自環境outファイル
Sections:Idx Name Size VMA LMA File off Algn 0 .vectors 00000058 80000000 80000000 00010000 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .text 001037b0 80000080 80000080 00010080 2**6 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 0000b3c8 80103830 80103830 00113830 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .ARM.extab 0000000c 8010ebf8 8010ebf8 0011ebf8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .ARM.exidx 000000f0 8010ec04 8010ec04 0011ec04 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .data 00036153 8010ecf8 8010ecf8 0011ecf8 2**3 CONTENTS, ALLOC, LOAD, DATA 6 .bss 00081720 80144e50 80144e50 00154e4b 2**3 ALLOC 7 .system 001c1108 801c6570 801c6570 00154e4b 2**2 ALLOC 8 .sdram 04000000 c0000000 c0000000 00160000 2**0 ALLOC 9 .vram 03bf0000 80400000 80400000 00160000 2**2 ALLOC 10 .mram 00010000 83ff0000 83ff0000 00160000 2**0 ALLOC 11 .stack 00008000 fe000000 fe000000 00160000 2**0 ALLOC 12 .debug_frame 000024a4 00000000 00000000 00154e4c 2**2 CONTENTS, READONLY, DEBUGGING, OCTETS 13 .comment 000000a3 00000000 00000000 001572f0 2**0 CONTENTS, READONLY 14 .ARM.attributes 00000035 00000000 00000000 00157393 2**0 CONTENTS, READONLY
と、大きな違いとしてはdebug_frame以外のdebug_*が含まれておらず、また、他の配置アドレスについても差分があることがわかりました。
mapファイルを見るとdebug_*に含まれているのは主にライブラリ関連の項目のようなので、そちらの参照が上手くいっていないことを疑ってみようかと思います。
mapファイルは前任者と私で差分がないのに、何故outファイルにすると差分が出るのかは疑念が尽きないのですが…
プロジェクトにビルド構成(Build configuration)が2つあって、片方はReleaseでビルド(デバッグ情報なし)、片方はDebugでビルド、みたいなことになっているのでは？どのビルド構成をactiveとするかはワークスペース側で持っているので(プロジェクト名の上で右クリック→「ビルド構成」(Build configurations)→「アクティブにする ＞」(Set Active))、プロジェクトをインポートした時に必ずしも同じ方が選択されているとは限りません。ビルド構成が複数あるなら、全部ビルドしてみてどれが一致しそうか確認してみてください。
>ほやさん>プロジェクトにビルド構成(Build configuration)が2つあって、片方はReleaseでビルド(デバッグ情報なし)、片方はDebugでビルド、みたいなことになっているのでは？ビルド構成はA_Debug/A_Release/M_Debug/M_Releaseの4つになっていてA_*がメインアプリ、M_*がメンテナンスアプリとなっており、そのうちのA_Releaseでビルドを行っていました。SVN上には、A_ReleaseとM_Releaseでビルドした結果しか残されておらず、前任者と私でA_Releaseでビルドした結果で差分が生じている、というのが現状です。(M_Releaseについてもビルドしてみましたが、同じように前任者と私でバイナリに差分が生じました）
また、mapファイルに差分がないと話をしていましたが、実際にビルドをしてみると、SVNにコミットされているmapファイルとは異なる名前のmapファイルが出力されていることがわかりました。前任者がビルドした際の正しいmapファイルは残されていないようでした。
mapも残っていないのでは、makefile等(*.mk等も含め)も残っていないのでしょうね。それらを比較すればオプションも確認できるはずですが。中間ファイルはSVNの管理対象にしたくないでしょうから、バックアップは別途取っておく必要があります。
調査を続けていますが、該当のプロジェクトだけ、動作するバイナリが作れない状況が現在も続いています。
同じCPUを使用する他プロジェクトの場合は、SVNにあるものとほぼ同じバイナリ(違いがタイムスタンプのみ)がビルド出来ているので、該当プロジェクトだけが異常なビルド結果になっている状況です。
また、他プロジェクトの設定を移植してビルドしてみましたが、状況は変わらずでした。