W0561321(エントリ・シンボル定義のあるオブジェクト・ファイルを複数入力しました)が発生してしまいます

お世話になっております。

先日、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.mot
W0561321:Entry symbol "_R_TBL" in "DefaultBuild\main2.obj" conflicts
W0561321:Entry symbol "_R_TBL" in "DefaultBuild\main3.obj" conflicts
Renesas Optimizing Linker Completed
------ ビルド終了(エラー:0個, 警告:2個)(test, DefaultBuild) ------

 

「エントリ・シンボル定義のあるオブジェクト・ファイルを複数入力」というのは、

どのような状態のことを指しているのでしょうか。

また、どこを直せばワーニングが消えますでしょうか。

よろしくお願い致します。

  • 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.mot
    W0561017:The evaluation period has expired
    W0561321:Entry symbol "_R_TBL" in "DefaultBuild\main2.obj" conflicts
    W0561321:Entry symbol "_R_TBL" in "DefaultBuild\main3.obj" conflicts
    W0561110: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.mot
    W0561017:The evaluation period has expired
    W0561110: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.mot
    W0561017:The evaluation period has expired
    W0561017:The evaluation period has expired


    以下、プロジェクトのファイル一式をzipファイルに固めました。

    issue_20210129_TestCCRLv110.zip

    フォルダ        プロジェクト            内容
    TestCCRLv109    TestCCRLv109.mtpj       CC-RL V1.09 RL78/G10 main2.c+main3.c
    TestCCRLv110    TestCCRLv110_1.mtpj     CC-RL V1.10 RL78/G10 main2.c+main3.c
    TestCCRLv110    TestCCRLv110_2.mtpj     CC-RL V1.10 RL78/G10 main2.asm+main3.c
    TestCCRLv110    TestCCRLv110_3.mtpj     CC-RL V1.10 RL78/G10 main2.asm+main3.asm
    TestCCRLv110_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.mot
    W0561017:The evaluation period has expired
    W0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\r_main.obj" conflicts
    W0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\r_cg_port.obj" conflicts
    W0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\task_CONIO.obj" conflicts
    W0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\task_LED0.obj" conflicts
    W0561321:Entry symbol "_renesas_simulator_debugging_key" in "DefaultBuild\task_LED1.obj" conflicts
    W0561110:Entry symbol "_start" in entry option conflicts
    RAMDATA 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=.const
    FILE=DefaultBuild\sim_debug_mode_hook.obj
                                      00003000  00003001         2
      _renesas_simulator_debugging_key
                                      00003000         2   data ,g         2
    FILE=DefaultBuild\freertos_start.obj
                                      00003002  00003045        44
    FILE=DefaultBuild\tasks.obj
                                      00003046  0000305b        16
      _uxTopUsedPriority
                                      00003046         2   data ,g         1
    FILE=DefaultBuild\timers.obj
                                      0000305c  00003063         8
    FILE=DefaultBuild\BlockQ.obj
                                      00003064  00003093        30
    FILE=DefaultBuild\blocktim.obj
                                      00003094  000030a1         e
    FILE=DefaultBuild\countsem.obj
                                      000030a2  000030ab         a
    FILE=DefaultBuild\death.obj
                                      000030ac  000030c3        18
    FILE=DefaultBuild\dynamic.obj
                                      000030c4  000030ea        27
    FILE=DefaultBuild\EventGroupsDemo.obj
                                      000030ec  00003100        15
    FILE=DefaultBuild\GenQTest.obj
                                      00003102  00003119        18
    FILE=DefaultBuild\QueueOverwrite.obj
                                      00003130  00003135         6
    FILE=DefaultBuild\recmutex.obj
                                      00003136  00003144         f
    FILE=DefaultBuild\semtest.obj
                                      00003146  00003165        20
    FILE=DefaultBuild\TaskNotify.obj
                                      00003166  00003184        1f
    FILE=DefaultBuild\TaskNotifyArray.obj
                                      00003186  000031a8        23
    FILE=DefaultBuild\TimerDemo.obj
                                      000031aa  000031e8        3f
    FILE=DefaultBuild\FreeRTOS_CLI.obj
                                      000031ea  000032d1        e8
      _xHelpCommand@1
                                      00003220         a   data ,l         1
    FILE=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         1
    FILE=DefaultBuild\UARTCommandConsole.obj
                                      0000356e  000035fd        90
    FILE=DefaultBuild\main_blinky.obj
                                      000035fe  00003627        2a
    FILE=DefaultBuild\main_full.obj
                                      00003628  0000386d       246
    FILE=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=.const
    FILE=DefaultBuild\sim_debug_mode_hook.obj
                                      00003000  00003001         2
      _renesas_simulator_debugging_key
                                      00003000         2   data ,g         2
    FILE=DefaultBuild\freertos_start.obj
                                      00003002  00003045        44
    FILE=DefaultBuild\tasks.obj
                                      00003046  0000305b        16
      _uxTopUsedPriority
                                      00003046         2   data ,g         1

     

  • NoMaYさま。いろいろと検証ありがとうございます。

    今、CS+を確認できない環境なので、細かなところは曖昧ですみませんが、

    こちらではその後、「ROMデータをfar領域に置く」的な設定を「はい」にしたところ、ワーニングが消えました。

    そこで、「はい」にする前と後のアセンブラ(main2.asmやmain3.asm)を確認してみたところ、R_TBLの宣言が、

    ・「はい」にする前(ワーニングが出る状況)

    $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が公開されましたら、
    そちらでご確認をお願いします。