お世話になっております。
先日、CS+forCCをアップデートしてから発生するようになったのですが、
ワーニングの説明にある「エントリ・シンボル定義のあるオブジェクト・ファイルを複数入力しました。」が理解できず、
対応に苦慮しております、どうかご助言をお願い致します。
こちらで発生している状況としましては、
CS+forCC V8.05.00
CC-RL V1.10.00
・新規プロジェクトでRL78/G10（R5F10Y47）（アプリケーション）を作成。
・コード生成ツールで「端子割り当て設定」だけ確定してコード生成。
・「r_cg_main.c」のmain関数内で、main2()関数を呼ぶように記述
・「main2.c」を作成し、下記のように記述
extern const unsigned char R_TBL[];void main3(void);static unsigned char c = 0;void main2(void){ unsigned char a,b; for (;;) { a = R_TBL[0]; b = R_TBL[1]; c += (a + b); main3(); }}
・「main3.c」を作成し、下記のように記述
extern const unsigned char R_TBL[];static unsigned char c = 0;void main3(void){ unsigned char a,b; a = R_TBL[0]; b = R_TBL[1]; c += (a + b);}
・「mem.c」を作成し、下記のように記述
const unsigned char R_TBL[] = {0,1};
・処理の内容については意味はありません、const宣言したROMデータを参照したいだけです。
・「main2.c」「main3.c」「mem.c」をプロジェクトに追加してビルドすると、
------ ビルド開始(test, DefaultBuild) ------>main2.c>mem.c>cg_src\r_cg_systeminit.c>cg_src\r_cg_cgc_user.c>cg_src\r_cg_wdt.c>cg_src\r_cg_main.c>main3.c>cg_src\r_cg_cgc.c>cg_src\r_cg_wdt_user.c>cstart.asm>DefaultBuild\test.abs DefaultBuild\test.motW0561321:Entry symbol "_R_TBL" in "DefaultBuild\main2.obj" conflictsW0561321:Entry symbol "_R_TBL" in "DefaultBuild\main3.obj" conflictsRenesas Optimizing Linker Completed------ ビルド終了(エラー:0個, 警告:2個)(test, DefaultBuild) ------
「エントリ・シンボル定義のあるオブジェクト・ファイルを複数入力」というのは、
どのような状態のことを指しているのでしょうか。
また、どこを直せばワーニングが消えますでしょうか。
よろしくお願い致します。
NoMaYさま。いろいろと検証ありがとうございます。
今、CS+を確認できない環境なので、細かなところは曖昧ですみませんが、
こちらではその後、「ROMデータをfar領域に置く」的な設定を「はい」にしたところ、ワーニングが消えました。
そこで、「はい」にする前と後のアセンブラ（main2.asmやmain3.asm）を確認してみたところ、R_TBLの宣言が、
・「はい」にする前（ワーニングが出る状況…
kinoko_makiさん、こんにちは。NoMaYです。＃お久しぶりです。私の理解は、エントリシンボルというのはCC-RXの#pragma entryで指定するリセット時実行関数のこと、というものです。つまり、本来、#pragma entryが(異なる関数に対して)複数のソースに記述されている場合にCC-RXで表示されるもの、であると思っていました。ちなみに、CC-RXの類似のワーニングに以下のものがあります。W0561110［メッセージ］ Entry symbol "シンボル" in entry option conflicts［説明］ entryオプションで指定した"シンボル"以外のシンボルがコンパイル、アセンブル時にエントリ・シンボルとして指定されています。オプション指定を優先します。ただ、この#pragma entryはCC-RLには存在しない#pragmaですし、明らかに今回のシチュエーションとも異なります。実は、CC-RXもCC-RLもリンカはrlink.exeというものでして、バイナリが同一かどうか比較したことが無いですが、仮にバイナリが同一では無いにしても元のソースコードに対して若干の#ifdef～#else～#endifで違いが出ているぐらいのものではないかと推測していたりします。まだ私はCC-RL V1.10をインストールしていませんが、予感としては、CC-RX向けに行った#pragma entryに関する改良がCC-RLで悪さをするようになってしまったのではないか、と疑っています。あるいは、素朴にCC-RLのコンパイラ側がバグってしまったのかも知れません。こういう場合の調査方法として、リストファイルやアセンブルソースファイルをコンパイラに生成させて、その内容を念のため確認してみる、というのがあります。明日、CC-RL V1.10をインストールして確認してみようと思っています。他にも、新旧のCC-RLでrlink.exeを交換して挙動がどう変化するかを調べるという手もあります。これも試してみようかと思います。
チョコです。
>・「r_cg_main.c」のmain関数内で、main2()関数を呼ぶように記述
CS+CC-RLではr_main.cだったと思うのですが。バージョンアップされて変わったのかな。
後で、ダウンロードして確認することにします。
以上
NoMaY さま。ありがとうございます。
こちらでもできることをやってみました。旧との比較ということで、下記を試してみました。
・使用するコンパイラパッケージのバージョンをV1.10.00→V1.09.00========== プロジェクトの差分情報 ==========test: CC-RL V1.10.00 -> V1.09.00 での変更点（全ビルド・モード）CC-RL (無効)[コンパイル・オプション]-[初期値なし変数をアライメント数に応じたセクションに分けて配置する]CC-RL (無効)[コンパイル・オプション]-[相対分岐命令のコードサイズを削減する]CC-RL (無効)[コンパイル・オプション]-[整列条件の変更による最適化を行う]CC-RL (無効)[コンパイル・オプション]-[const修飾変数をアライメント数に応じたセクションに分けて配置する]CC-RL (無効)[コンパイル・オプション]-[初期値あり変数をアライメント数に応じたセクションに分けて配置する]CC-RL (無効)[ヘキサ出力オプション]-[CRCの演算結果、および出力アドレスを表示する]========================================→ビルドすると、ワーニングの発生はなし。
・使用するコンパイラパッケージのバージョンを元に戻す（V1.09.00→V1.10.00）========== プロジェクトの差分情報 ==========test: CC-RL V1.09.00 -> V1.10.00 での変更点（全ビルド・モード）CC-RL (有効)[コンパイル・オプション]-[初期値あり変数をアライメント数に応じたセクションに分けて配置する] いいえCC-RL (有効)[コンパイル・オプション]-[const修飾変数をアライメント数に応じたセクションに分けて配置する] いいえCC-RL (有効)[コンパイル・オプション]-[整列条件の変更による最適化を行う] 最適化レベルに合わせる(オプション指定なし)CC-RL (有効)[コンパイル・オプション]-[相対分岐命令のコードサイズを削減する] 最適化レベルに合わせる(オプション指定なし)CC-RL (有効)[コンパイル・オプション]-[初期値なし変数をアライメント数に応じたセクションに分けて配置する] いいえCC-RL (有効)[ヘキサ出力オプション]-[CRCの演算結果、および出力アドレスを表示する] いいえ========================================→ビルドすると、ワーニングが発生する。差分の中でなんとなく関係がありそうな、初期値あり変数をほにゃららを「いいえ→はい」、const修飾変数をほにゃららを「いいえ→はい」を、片方ずつと両方同時を試してみましたが、ワーニングは消えませんでした。
・V1.09.00とv1.10.00の「bin」フォルダ内のrlink.exeを入れ替えてそれぞれビルド（これで本当に入れ替わっているかどうかは不明なのですが）rlink.exeを入れ替えても、ワーニングが出るのはV1.10.00の方でした。（rlink.exeが原因ではないかも？）
その他に、「mem.c」でのconst宣言をコメントアウトして、「main2.c」や「main3.c」の方で宣言すると、ワーニングが消えました。
リンク順の問題かもと思い、一番最後だったmem.objを先頭に持っていきましたが、ワーニングは消えませんでした、
チョコさま。
RL78/L12でコード生成した時は「r_main.c」が生成されましたが、今回RL78/G10でコード生成したら「r_cg_main..c」でした。2016年のG10のプロジェクトも見てみましたが「r_cg_main..c」だったので、今回のバージョンアップで変わったわけではなさそうです。
この違い、今まで全然気が付きませんでした。
RL78のコード生成には2系統があります。
RL78/G13のように古くからあるデバイスでは、r_main.cですが、RL78/G10あたりより新しいデバイスはr_cg_main.cでした。
最近はG10を使っておらず、G13やG14をよく使っていたので、忘れていました。
kinoko_makiさん、こんにちは。NoMaYです。私の手元でも同じワーニングが出ました。rlink.exを入れ替えても同じでした。更に、リンカオプションの-entryはCC-RLでも指定可能ですので、試しに-entry=_startとしてみたところ、私が昨日リプライに書いたCC-RXのW0561110が増えて以下の通りになりました。
>DefaultBuild\TestCCRLv110_1.abs DefaultBuild\TestCCRLv110_1.motW0561017:The evaluation period has expiredW0561321:Entry symbol "_R_TBL" in "DefaultBuild\main2.obj" conflictsW0561321:Entry symbol "_R_TBL" in "DefaultBuild\main3.obj" conflictsW0561110:Entry symbol "_start" in entry option conflicts ← つまり_R_TBLと_startがコンフリクトしたと思われるW0561017:The evaluation period has expired
他方、main2.cやmain3.cをアセンブラソースで置き換えてみたところ以下の通りとなり、これらのことから推測して、CC-RLのコンパイラ側がR_TBL[]をCC-RXの#pragma entry R_TBLと同等な取り扱いをしてしまったものをオブジェクトファイルとして生成してrlink.exe側に渡してしまっていることが原因だと推測される不具合のような気がします、、、main2.asm＋main3.c: 片方をアセンブラソース化したことで_R_TBL同士のコンフリクトは解消された模様
>DefaultBuild\TestCCRLv110_2.abs DefaultBuild\TestCCRLv110_2.motW0561017:The evaluation period has expiredW0561110:Entry symbol "_start" in entry option conflicts ← ただし_R_TBLと_startは依然コンフリクトしていると思われるW0561017:The evaluation period has expired
main2.asm＋main3.asm: 両方をアセンブラソース化したことで_R_TBLと_startのコンフリクトも解消された模様
>DefaultBuild\TestCCRLv110_3.abs DefaultBuild\TestCCRLv110_3.motW0561017:The evaluation period has expiredW0561017:The evaluation period has expired
以下、プロジェクトのファイル一式をzipファイルに固めました。issue_20210129_TestCCRLv110.zip
フォルダ プロジェクト 内容TestCCRLv109 TestCCRLv109.mtpj CC-RL V1.09 RL78/G10 main2.c＋main3.cTestCCRLv110 TestCCRLv110_1.mtpj CC-RL V1.10 RL78/G10 main2.c＋main3.cTestCCRLv110 TestCCRLv110_2.mtpj CC-RL V1.10 RL78/G10 main2.asm＋main3.cTestCCRLv110 TestCCRLv110_3.mtpj CC-RL V1.10 RL78/G10 main2.asm＋main3.asmTestCCRLv110_b TestCCRLv110_b.mtpj CC-RL V1.10 RL78/G13 main2.c＋main3.c (RL78/G10のみでなくRL78/G13でも発生)
kinoko_makiさん、こんにちは。NoMaYです。私の手持ちのプロジェクトをCC-RL V1.10でビルドしたところ、そちらでも同様のワーニングが出ましたね。(RL78/G14, FreeRTOS RTOSDemo Project, RL78/G14 Fast Prototyping Board)
>DefaultBuild\RTOSDemo.abs DefaultBuild\RTOSDemo.motW0561017:The evaluation period has expiredW0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\r_main.obj" conflictsW0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\r_cg_port.obj" conflictsW0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\task_CONIO.obj" conflictsW0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\task_LED0.obj" conflictsW0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\task_LED1.obj" conflictsW0561110:Entry symbol "_start" in entry option conflictsRAMDATA SECTION: 00005b05 Byte(s)ROMDATA SECTION: 00000c1f Byte(s)PROGRAM SECTION: 00008292 Byte(s)W0561017:The evaluation period has expired
sim_debug_mode_hook.hというヘッダで以下のように宣言、各ソースでインクルード
extern const unsigned short renesas_simulator_debugging_key;
sim_debug_mode_hook.cというソースで以下のように定義
const unsigned short renesas_simulator_debugging_key = 0xFFFF;
なお、const変数自体は以下の通り結構使っていますので、ワーニングがこれだけしか出ないのは、何か条件がありそうな予感もしましたが、ただ、文字列定数(とスタティックconst変数)ばかりで結局const変数をexternで参照していた変数はこれのみだった、という顛末の可能性もあるかも知れません、、、RTOSDemo.mapから抜粋
*** Mapping List ***SECTION START END SIZE ALIGN略.const 00003000 000038f3 8f4 2
*** Symbol List ***SECTION=FILE= START END SIZE SYMBOL ADDR SIZE INFO COUNTS OPT略SECTION=.constFILE=DefaultBuild\sim_debug_mode_hook.obj 00003000 00003001 2 _renesas_simulator_debugging_key 00003000 2 data ,g 2FILE=DefaultBuild\freertos_start.obj 00003002 00003045 44FILE=DefaultBuild\tasks.obj 00003046 0000305b 16 _uxTopUsedPriority 00003046 2 data ,g 1FILE=DefaultBuild\timers.obj 0000305c 00003063 8FILE=DefaultBuild\BlockQ.obj 00003064 00003093 30FILE=DefaultBuild\blocktim.obj 00003094 000030a1 eFILE=DefaultBuild\countsem.obj 000030a2 000030ab aFILE=DefaultBuild\death.obj 000030ac 000030c3 18FILE=DefaultBuild\dynamic.obj 000030c4 000030ea 27FILE=DefaultBuild\EventGroupsDemo.obj 000030ec 00003100 15FILE=DefaultBuild\GenQTest.obj 00003102 00003119 18FILE=DefaultBuild\QueueOverwrite.obj 00003130 00003135 6FILE=DefaultBuild\recmutex.obj 00003136 00003144 fFILE=DefaultBuild\semtest.obj 00003146 00003165 20FILE=DefaultBuild\TaskNotify.obj 00003166 00003184 1fFILE=DefaultBuild\TaskNotifyArray.obj 00003186 000031a8 23FILE=DefaultBuild\TimerDemo.obj 000031aa 000031e8 3fFILE=DefaultBuild\FreeRTOS_CLI.obj 000031ea 000032d1 e8 _xHelpCommand@1 00003220 a data ,l 1FILE=DefaultBuild\Sample-CLI-commands.obj 000032d2 0000356d 29c _xTaskStats@1 00003328 a data ,l 1 _xThreeParameterEcho@2 000033a6 a data ,l 1 _xParameterEcho@3 00003414 a data ,l 1 _xQueryHeap@4 0000347c a data ,l 1FILE=DefaultBuild\UARTCommandConsole.obj 0000356e 000035fd 90FILE=DefaultBuild\main_blinky.obj 000035fe 00003627 2aFILE=DefaultBuild\main_full.obj 00003628 0000386d 246FILE=DefaultBuild\task_CONIO.obj 0000386e 000038f3 86
[追記]未使用の変数/関数を削除する最適化を指定していましたので、リンカのワーニングの数と最適化後のMOTファイルに対するMAPファイルに情報に若干のズレがありましたが、参照COUNTS数の情報から判断すれば、結局const変数をexternで参照していた変数はこれのみだった、ということのようでした、、、
*** Symbol List ***SECTION=FILE= START END SIZE SYMBOL ADDR SIZE INFO COUNTS OPT略SECTION=.constFILE=DefaultBuild\sim_debug_mode_hook.obj 00003000 00003001 2 _renesas_simulator_debugging_key 00003000 2 data ,g 2FILE=DefaultBuild\freertos_start.obj 00003002 00003045 44FILE=DefaultBuild\tasks.obj 00003046 0000305b 16 _uxTopUsedPriority 00003046 2 data ,g 1略
・「はい」にする前（ワーニングが出る状況）
$mirror R_TBL
・「はい」にした後（ワーニングが出ない）
.EXTRN R_TBL
になっていました。
farに置かない場合は、おそらくミラー領域の方を参照しに行くよう、最適化されているのだと思うのですが、
リロケートする時に$mirrorが想定外の値（entyと同じ意味の値とか）に置き換わっている、とかでしょうか。
しばらくはV1.09.00で運用しますが、不具合かも？とのことなので、
来週、もう一度状況をまとめて、お問い合わせの方から報告してみたいと思います。
RL78/G10のミラー領域は他のRL78と異なる方式になっています。すべてのコード・フラッシュ領域がミラー領域からアクセスできるはずなのですが、それがうまく処理されていないのかもしれませんね。
そうなると、CC-RLの不具合の可能性も否定できませんね。
状況はいかがでしょうか。
当方もCC-RL V1.10.00で、ワーニングW0561321が発生しました。
なぜか__far 領域に指定したところワーニングは消えました。
怖いので、当面はV1.09.00に戻しております。
tron様遅くなり申し訳ありません。
問い合わせましたところ、CC-RL V1.10でW0561321警告メッセージが発生しても、出力されるコードに問題はないそうです。
ただ、回避方法等については見直しを行っていて、FAQを公開する予定で進めているとのことでした。
詳細につきましては、FAQが公開されましたら、そちらでご確認をお願いします。