1.
Q. コンパイラをサイレントインストールする方法について A. コンパイラのサイレントインストールがうまくいかない場合、 EULAの同意部分に失敗していることが考えられます。 下記の通りに指定しますと、インストール可能です。 start /wait msiexec /qn /i nintendo.msi /l*v nintendo_install.log EULA=1 [オプションについて] /qn: quiet install mode /i: install /l*v log all the information EULA=1 accepting EULA from command line |
2.
Q. コンパイラ が C9932E エラーを返すときの対応について コンパイル時に、コンパイラ が以下のメッセージを出力してエラーとなる ことがあります。 Error: C9932E: Cannot obtain license for Compiler (feature besp_compiler_00) with license version >= 4.0 System clock has been set back For further information, refer to the FLEXnet Licensing documentation, available at "www.acresso.com". A. コンパイラ のライセンスファイルではランダムに PC 上のファイルをチェックしており、 不正なタイムスタンプ(未来の日時)のファイルが存在した場合に上記エラーが発生します。 上記エラーが発生した場合は、Windowsのファイル検索でタイムスタンプが未来の日時になっているものを 検索し、修正することで解決できます。 具体的には、cygwin 上で下記のコマンドを実行することで、該当ファイルを修正できます。 $ cd /cygdrive/c $ find -type f -mmin -1 -exec touch {} \; $ find -type f -amin -1 -exec touch {} \;なお、ファイルのチェックはごみ箱の中身も対象となっているため、 上記のチェックで問題が解決しない場合、ごみ箱を空にして試してください。 |
3.
Q. atan2f() を atan2f(0.f, 0.f) として呼んだ場合の挙動について atan2f() を、atan2f(0.f, 0.f) として呼んだ場合、CTR の開発環境(RVCT4.0)では NaN が返されますが、本来は0.0が返されるべきではないでしょうか?A. ISO 仕様では、上記関数で範囲外の引数が与えられた場合の挙動は 実装者に任せられており、RVCT4.0 の ARM Cライブラリでは NaN を返します。 その他の関数に関しての挙動は、パッケージ内のライブラリガイド(rvct_libraries_guide.pdf) の2.14を参照してください。 ARMCC4.1 では、特殊なケースでの数学関数の戻り値が POSIX/C99 要件に準拠するようになり、0.0f が返されるようになりました。 |
4.
Q. すべてのwarningをerrorにする方法について A. コマンドラインオプションに--diag_error=warningを追加すると、 全ての警告をエラーにすることができます。 |
5.
Q. --fpmode=fast 指定時に非有限値を扱うことができません A. --fpmode=fast 指定時には、IEEEで規定されている非有限値の取り扱いは完全に対応しておらず、 全ての最適化レベルによって同一の振る舞いを保証していません。 演算にNaNが想定されるような場合には、isnan()関数で事前に処理を切り分けるなどの対応をして下さい。 |
6.
Q. --enum_is_int を指定してアプリケーションをビルドできません A. CTR-SDKは --enum_is_int を無効にしてビルドされています。 ライブラリとアプリケーションで、このオプションを変更してビルドすることはできません。 また、CTR-SDKで --enum_is_int オプションを有効にする予定はありません。 |
7.
Q. 最適化に関する不具合への対策について A. 現状、-O3 -Otimeの組み合わせで使用した際に不具合が発生するケースが多いようです。 このオプションの組み合わせではループ最適化の機能が有効になるのですが、 この機能で不正な最適化を行ってしまうケースが幾つか発生しています。 対策としては、下記の方法があります。 ■不正なコードを生成する関数を特定できていない場合 ・ソースコードの先頭に以下の記述を追加し、ソースコードの最適化レベルを変更する。 #pragma Ospace ・特定の最適化レベルが指定されたときのみ最適化レベルを変更する。 #if __OPTIMISE_LEVEL == 3 #ifdef __OPTIMISE_TIME #pragma Ospace #endif #endif ■不正なコードを生成する関数が特定できている場合 ・特定の関数だけの最適化レベルを変更する。 #pragma push #pragma Ospace void foo() { ... } #pragma pop ・-O3 -Otimeで有効になるループ最適化機能のみを無効にする。 #pragma push #pragma Ono_vast void foo() { ... } #pragma pop ※この Ono_vast オプションは、ドキュメント化していない非公開のオプションですが、 この指定でループ最適化機能だけを無効にすることが出来ます。 |
8.
Q. std::bitsetでto_string関数を使うとコンパイルエラーが発生します 下記のようなコードをコンパイルすると、(a)の箇所でコンパイルエラーになります。 std::string foo() { std::bitset<10> bits = 100; std::string str = bits.to_string(); // ---(a) return str; } A. C++標準のライブラリ仕様では、to_stringはテンプレートメンバ関数を 使用するものが定義されているため、本症状は仕様となります。
正しい呼び出し方法は下記の通りとなります。
std::string str = bits.to_string< char, std::char_traits また、非推奨ではありますが、_RWSTD_NO_MEMBER_TEMPLATES をマクロ名としてコンパイラに渡すことで、 非テンプレートメンバ関数版を使用することも可能です。
使用例: armcc -c test.cpp -D_RWSTD_NO_MEMBER_TEMPLATES |
9.
Q. 先行宣言と実際の宣言で、クラスと構造体を間違えてもコンパイルエラーにならない A. 上記はコンパイラの仕様となります。 C++における struct と class の違いは、デフォルトのアクセス指定だけのため、 それが原因でソースコードの記述が問題とならなければ、ワーニングやエラーになりません。 |
10.
Q. プリコンパイルヘッダ使用時にコンパイラが出力するメッセージを非表示にする方法について A. --no_pch_messagesコマンドを追加することで、プリコンパイルヘッダ関連のメッセージを抑止することができます。 |
11.
Q. テンプレート関数からstaticな関数を呼んだ場合に、コンパイルエラーが発生します A. C++標準の[14.6.4.2]で定義されている依存名のルックアップ手続きに従い、外部リンケージを持つ 名前だけがルックアップの対象となっているためで、仕様となります。 ttp://www.csci.csusb.edu/dick/c++std/cd2/template.html#temp.dep.candidate なお、RVCTには、依存名に関して GCC や VC++ と同等の振る舞いを行う--no_dep_name オプションがあります。 --no_dep_name を追加すると、テンプレートが解析されるときの依存名のルックアップは無効になるので、 エラーの発生を抑止することができます。詳細は、コンパイラリファレンスガイドの「--dep_name,--no_dep_name」 の項目をご参照下さい。 |
12.
Q. C形式のソースからバイナリファイルを生成する方法について C形式のソースファイルからarmcc、armlinkを使用してaxfを作成し、fromelfでバイナリファイルを 作成したいのですが、リンク時にL6048Uのエラーが出ます。 A. RVCT4.0 20100909版より、ライセンス保護の仕組み上、上記のような使い方ができないようになりました。 申し訳ありませんが、別の方法をご検討いただきますようお願いいたします。 |
13.
Q. --gnu 指定時に警告メッセージ #94 「配列のサイズはゼロより大きくする必要があります」 を表示する方法について A. --gnu 指定時に警告メッセージ #94 を表示することは出来ません。 |
14.
Q. 浮動小数点数から整数への暗黙的なキャストが行われた際に警告を出す方法について A. 現在のコンパイラではこのような機能はありません。 機能追加を検討していますが、ARMCC 5.x での対応予定はありません。 |
15.
Q. 構造体を含む構造体配列で、本来最適化によって呼ばれるべきではないaeabi_vec_ctor_nocookie_nodotrが呼び出されています 下記のようなコードで、デフォルトコンストラクタを定義すると、コンストラクタが本来最適化されてなくなるはずが、 aeabi_vec_ctor_nocookie_nodotrが呼び出されています。 デフォルトコンストラクタを定義しなければ、この症状は発生しません。 struct Point { int x; int y; int z; // Comment this out in order to see "inlined" version Point() {} }; struct Line { Point ends[2]; }; extern "C" void nnMain() { Line lines[10] __attribute__((unused)); while(1){} } A. 現状のコンパイラでは、そのような最適化を行っていません。 修正を検討していますが、ARMCC 5.x での対応予定はありません。 |
16.
Q. メンバ変数と同じ名前のオート変数を定義したときに警告を出す方法について A. 現状では警告を出すことはできません。 機能追加を検討していますが、ARMCC 5.x での対応予定はありません。 |
17.
Q. --ltcgオプションの使用方法について A. 現状--ltcgオプションを使用することはできません。 使用できるように改善を検討しておりますが目処が立っておりません。 --multifile機能を使用することで、同等のことを実現することができます。 |
18.
Q. VFP ベクターモードの使用可否について A. VFP ベクターモードは使用していただいて問題ありません。 RVCT のパッケージに含まれるドキュメント(DUI0204IJ_rvct_assembler_guide.pdf)の「5.17 VFP ベクタモード」には、 「 VFP ベクタモードの使用は廃止される予定です」という記述がありますが、CTRでのVFPベクタモードの使用が廃止されるという意味ではありません。 また、ドキュメントには「単一命令複数データ処理(SIMD)による並列処理が可能です」という記述がありますが、VFPは複数の演算を並列に行うのではなくシリアルに演算するもので、所謂「並列処理」という意味ではありません。 |
19.
Q. --fpmode=ieee_no_fenv オプションを使用したときの例外に関する挙動について コンパイラリファレンスガイドには、--fpmode=ieee_no_fenv を使用すると例外が発生されない、と書かれていますが、 この fpmode でデバッグした際に、プロセスが終了されることがあります。 A. CTR-SDK では --fpmode=fast の指定が必須であり、--fpmode=ieee_no_fenv 指定時の動作はサポートしていません。 なお、コンパイラのマニュアルに記載されているとおり、--fpmode=ieee_no_fenv 指定時には、下記の例外は発生しなくなります。
Signal NaN, Quiet NaNが演算で使用された場合の挙動は、テクニカルリファレンスマニュアルの 『第17 章 VFP プログラマモデル 17.2.3 IEEE 754 規格実装の選択』の『表17-2 QNaN と SNaN の処理』に説明があります。 --fpmode=ieee_no_fenv を使用した場合、デフォルト NaN モードはオフになるため、例えば FCMPE 命令(VCMPE と等価です)で Quiet NaN がオペランドにある場合には、表中に説明があるように『INV がセットされます。操作の処理がサポートコードに バウンスされます。』となり、入力例外フラグがセットされ、例外が発生します。 一方、--fpmode=fast または --fpmode=std の場合は、_fp_init でデフォルト NaN モードをオンに設定するライブラリが リンクされるため、例外処理は発生しません。 --fpmode=fast と --fpmode=ieee_* でコンパイルされたオブジェクトが混在する場合には、 リンカは、--fpmode=ieee_no_fenv と同様に IEEE 標準の初期化を行い、デフォルト NaNモードがオフになります。 上記理由により、--fpmode=ieee_no_fenv を CTR 環境で使用した場合には、VFP 初期化部分でデフォルト NaN モードが オフになり、例外処理が発生します。 |
20.
Q. ビルド時に #1620-D: Internal fault: translation failed. Please contact your supplier (ipa_nfuncs) というエラーが出る A. この内部エラー表示は実際には、診断メッセージが出力した 'internal fault' 文字列であり、エラーではありません。 このメッセージは、--remarks オプションにより発生し、なぜ各種最適化が失敗したかを表示しています。 上記のケースでは、変換ユニット内で10000を越える関数が含まれているために、最適化が難しく処理に失敗していることを 表しています。関数が10000以内になるよう、複数の変換ユニットに分割することで、この診断メッセージは表示されなくなり、 最適化が行われるようになります。 |
21.
Q. Releaseビルド時に、thisポインタの NULL チェックを行うコードが生成されません A. this ポインタが NULL の状態で、メンバ関数を呼び出した際の実装は未定義です。 RVCT では、デフォルトで最適化時に NULL チェックのコードを削除するため、本件は実装仕様となります。 コマンドラインオプション --allow_null_this を使うことで、this ポインタの NULL チェックを有効にし、 最適化による削除を無効にすることができます。 |
22.
Q. オブジェクトレベルでinline展開を行う方法について リンカで--inlneを指定した場合に、少し複雑な関数でもリンカレベルでインライン展開する方法はないでしょうか? A. リンカでのインライン展開は、コンパイラが生成した関数コール部分のコードに関数の実体を挿入する機能のため、 複雑なインライン処理を行うことは出来ません。--multifileオプションの利用をご検討下さい。 |
23.
Q. ヒープからではなく、スタックからアロケートする方法について A. ARMCC4.1 b640より、alloca関数を使用することでスタックからアロケートできます。 RVCT4.0では対応予定はありません。 |
24.
Q. プリコンパイルヘッダの作成側と参照側で統一させるべきコンパイルオプションの並び順について A. コンパイラはコマンドラインまたはviaファイル経由のオプションを種類ごとにソートしてから使用します。 複数の該当オプション(例えば、-I)の間に別の種類のコンパイラオプションが指定されていても、種類ごとに ソートされた後の順番が一致していればコマンドライン指定が同じであると認識されます。
例えば: --create_pch=file.pch -O3 -Iaaa -Otime -Ibbb --use_pch=file.pch -O3 -Otime -Iaaa -Ibbb という二つのコマンドライン指定は、 -O3 -Otime -Iaaa -Ibbbという種類順でソートされますので、プリコンパイルヘッダを使用することが可能です。 これに該当するオプションは、-D/-U/-I/-J/--preincludeのように、複数回指定できるオプションが該当します。 --diag_suppressなどのように一つのオプション指定で複数の要素が設定できる場合は、要素を単純に連結して処理します。 例えば: --diag_suppress=1 --diag_suppress=2 --diag_suppress=3 は、以下のように変換されます。 --diag_suppress=1,2,3 一方、 --diag_suppress=1,3 --diag_suppress=2 は、以下の様に連結されるため注意が必要です。 --diag_suppress=1,3,2なお、 種類順にソートされた結果は、以下のいずれかで確認することが出来ます。
|
25.
Q. ライブラリ内の非 weak シンボルより、weak シンボルが優先してリンクされることがあります A. ライブラリ内の非 weak シンボルは、使用方法によっては先にリンクされている weak シンボルを 置き換えないことがあります。この動作は、RVCT リンカの仕様です。 RVCT コンパイラリファレンスガイドの「4.1.19 __weak」には以下のように記載されています。 -- リンカは、他のコンパイルで関数や変数が非 weak で使用されている場合を除き、 ライブラリから関数や変数をロードしません。 -- weak シンボルを、ライブラリ内の非 weak シンボルで置き換えようとする場合、実際に置き換えられているかどうか注意してください。 この仕様の改善について検討を行いましたが、変更の予定はありません。 |
26.
Q. プリコンパイルするヘッダ内で、#pragma diag_suppress を使用した場合、プリコンパイルヘッダ生成時には pragma が有効になりますが、プリコンパイルヘッダ使用時に pragma が有効になりません A. これは、プリコンパイルヘッダの仕組みとして正しい振る舞いです。 この動作が問題となる場合には、以下のいずれかの方法をご検討下さい。
main.cpp ソースファイルの例: #include "main.h" #pragma diag_suppress 177 main.cpp ソースファイルの例: #include "main.h" #pragma hdrstop // プリコンパイルヘッダ生成の終了 #include "user.h" // このファイル内に #pragma diag_suppress を記述する |
27.
Q. メンバ関数の定義の際にクラス名を多重に書いてもエラーになりません 下記のようなコードでエラーが検出されません。 例) class MyClass { public: MyClass(); ~MyClass(); void DoAnything(); }; MyClass::MyClass::MyClass() {} // no error MyClass::MyClass::MyClass::~MyClass() {} // no error void MyClass::MyClass::MyClass::MyClass::DoAnything() {} // no error A. C++標準仕様の9.0.2章に関連した記述があり、C++の仕様となります。
A class-name is inserted into the scope in which it is declared immediately after the class-name is seen. The class-name is also inserted into the scope of the class itself; this is known as the injected-class-name. For purposes of access checking, the injected-class-name is treated as if it were a public member name. 【JIS X3014での翻訳】 ≪クラス名≫は、≪クラス名≫が現れると即座に、宣言される有効範囲に加えられる。 ≪クラス名≫は、クラス自身の有効範囲にも加えられる(補正クラス名と呼ぶ。)。 アクセス検査に当たっては、補正クラス名は、公開メンバ名であるかのように扱われる。このクラス名は、そのクラスの有効範囲に挿入されたクラス名(injected-class-name)です。 |
28.
Q. インクルードパスを再帰的に検索する方法について A. インクルードパスを再帰的に検索する方法はありません。 また、機能追加の予定もありません。 |
29.
Q. __align に 16 や 32 を指定できません A. 上記はコンパイラの仕様となります。 また、他のツールにも影響を及ぼす部分であるため、対応する予定はありません。 |
30.
Q. -Otime -O3 と -Otime -O2 との最適化の違いについて A. -Otime -O3 では、以下の特徴があります。
|
31.
Q. #2819-D の診断メッセージについて テンプレートクラス内で仮想関数を使用すると、#2819-D の診断メッセージが表示されますが、 「テンプレートメンバ関数の暗黙的インスタンス化がキー関数として選択される」とはどういう意味でしょうか? A. 本診断メッセージは、キー関数がテンプレートメンバ関数だった場合に、暗黙的にインスタンス化されることを 通知するための診断メッセージです。 (キー関数とは、クラスで最初に宣言される、インライン関数ではなく、純粋仮想関数でない仮想関数です。) 下記の対応で回避することができます。
|
32.
Q. インラインアセンブラで、GCC のassmebler instruction template のような記法に対応する予定について A. 追加機能として検討されていますが、長期的な計画として検討されているため、 ARMCC 5.x での対応予定はありません。 |
33.
Q. --create_pch で作成したプリコンパイルヘッダを使用するとエラーが出ます A. --create_pch で作成したプリコンパイルヘッダを使用する際には下記の点に注意してください。
|
34.
Q. --create_pch/--use_pch を使用する際に、-I オプションに相対パスを使用できるか A. 既存の動作に対する互換性の問題から、現時点では対応の予定はありません。 |
35.
Q. --split_sections を指定しても、組み込みアセンブラで記述された関数がデッドストリップされません A. --split_sections が組み込みアセンブラで記述した関数で有効にならないのは仕様です。 下記の通り、#pragma arm section を使用して関数単位でセクション名を明示的に設定する必要があります。 #pragma push #pragma arm section code="AAAA_Asm" AAAA_Asm() {...} #pragma arm section code="BBBB_Asm" BBBB_Asm() {...} #pragma arm section code="CCCC_Asm" CCCC_Asm() {...} : 省略 #pragma pop |
36.
Q. コンパイラが挿入したパディングの位置を知る方法について クラスや構造体のアライメントのために以下の警告が出ますが、これがどこに、何バイトの パディングを挿入したか知る方法はありますか? #1301-D: padding inserted in XXXXX A. 現状ではありません。 ARMCC 5.x での対応予定はありません。 |
37.
Q. __forceinline を指定した関数を複数回呼び出すコードが最適化されません __forceinline を指定した関数を複数回呼び出すようなコードを -O3 -Otime でビルドした際に、 最適化が期待通りに行われませんが、改善される予定はありますか? A. 改善が検討されていますが、ARMCC 5.x での対応予定はありません。 マクロを使用した場合は、重複した関数呼び出しのうち、最後の1回だけがコードとして残ります。 |
38.
Q. コンパイラで使用可能な文字コードについて
A.
ARMCCでのマルチバイトコードの扱いは、使用するホストOSに依存します。 また、コンパイル後のオブジェクトファイルの文字コードは、マルチバイト文字では ソースコードと同じ文字コードに、ワイド文字列ではUTF-16LEとなります。 |
39.
Q. スタティックイニシャライザの挙動について インラインでコンストラクタを書いた場合以下のようなソースコードのビルドが通ります。 --- ・A.cpp #include <nn.h> class C { public: C() { NN_LOG("AAA:%s(%d)\n", __FILE__, __LINE__); } }; C A; --- ・B.cpp #include <nn.h> class C { public: C() { NN_LOG("BBB:%s(%d)\n", __FILE__, __LINE__); } }; C B; ---
これを実行すると、インスタンスA、Bのスタティックイニシャライザはコンストラクタを A.
ビルドオプションに、--retain=calls を指定している場合、スタティックイニシャライザによる __sti___5_A_cpp PROC PUSH {r4,lr} LDR r0,|L1.16| BL _ZN1CC1Ev ; C::C() の呼び出し POP {r4,pc} ENDPこれにより、クラス C のコンストラクタ _ZN1CC1Ev への参照が発生します。 リンカはこれを解決しますが、クラス C のコンストラクタ_ZN1CC1Ev は同名で 複数のオブジェクト内で定義されており、これらは同名の共通グループ(COMGROUP)が 使用されます。 AREA ||i._ZN1CC1Ev||, COMGROUP=_ZN1CC1Ev, CODE, READONLY, ALIGN=2 _ZN1CC2Ev ; Alternate entry point _ZN1CC1Ev PROCドキュメント「リンカの使用」内の「5.2 共通グループまたは共通セクションの削除」に 説明があるように、リンカは最初に検出したグループを保持し、それ以外を削除します。 このため、多重定義などのリンクエラーは発生しません。
--retain=calls を指定しなかった場合、コンストラクタはインライン展開され、 __sti___5_A_cpp PROC MOV r2,#6 ADR r1,|L1.16| ADR r0,|L1.52| B _ZN2nn3dbg6detail6PrintfEPKczこれにより、同一変換ユニット内のそれぞれのコンストラクタが呼び出されます。 --retain=calls 以外でも、--no_inline を指定した場合は、コンストラクタはインライン展開 されませんので、同名のコンストラクタを別のコンパイル単位で意図的に使用する場合には、ご注意下さい。 |
40.
Q. 配列へのポインタの扱いについて 以下のコードをコンパイルしても、エラーにならず通ってしまいます。 char (*str)[256] = new (char(*)[256])[2];右辺は「配列へのポインタ」ですが左辺は「配列へのポインタの配列(の先頭アドレス)」なので、 間接参照のレベルが違います。左辺について、配列へのポインタの配列というのはそもそも new できる ものなのでしょうか。(VisualStudio 2008 ではできませんでした) A.
上記コードは、以下の様に置き換えることが出来ます。 typedef char(*the_type)[256]; the_type str = new (the_type)[2];ここでの式 'new (the_type)[2]' は、C++では有効な記述ではないため、厳密なC++準拠を指定する モード(--strict)ではエラーになります。また、--strict_warnings では、警告メッセージが表示 されます。デフォルトの非厳密モード(--no_strict)では、以下の様に取り扱います。 the_type str = (new (the_type))[2];the_type は、256 chars の配列へのポインタです。(new (the_type))は、このポインタをアロケートし、 このアドレスを返します。(new (the_type))[2] はこれを行い、その後に配列として返される値を扱い、 その二番目の(the_type 型を持つ)要素を返します。 配列へのポインタの配列をアロケートする場合には、以下の様になります(明確にするため、ここでもtypedefを使用します) typedef char array_type[256]; typedef array_type *array_type_ptr; array_type_ptr *str = new array_type_ptr[2];これは 256 chars の配列へのポインタの2つの要素を持った配列をアロケートし、'str' にポインタの 配列の最初の要素をセットします。
C++標準規格では、new expression でパーレン(丸括弧)の使用は'can have surprising effects' |
41.
Q. 無名名前空間の大域変数を組み込みアセンブラから使う方法について
無名名前空間内にある変数のアドレスを得たいのですが、うまくいきません。 namespace{ float localValue; asm float *GetLocalValueAddr() { LDR r0,=__cpp(&localValue) BX lr } } main() { NN_LOG("local Addr:%p\n",GetLocalValueAddr()); } A.
組み込みアセンブラで記述した __asm 関数は同一変換ユニット内での複数の __asm 関数が
__cpp キーワードでは、外部リンケージを使用するデータまたは関数アドレスのみを取り扱う |
42.
Q. ARMCC での C++0x(C++11) の導入について A.
ARMCC5.x での対応を検討しています。 |
43.
Q. fast ビルド時に、ARMv5T 用ではなく ARMv4 用のライブラリがリンクされます A.
リンカのデフォルトオプションでは、入力オブジェクトが ARM コードのみである場合は、
リンカのオプションに --cpu=MPCore を指定することで、入力オブジェクトがARM コードのみの CTR-SDK 4.0 のビルドルールで、リンカのデフォルトオプションに --cpu=MPCore が追加されました。 |
44.
Q. コンパイラを ARMCC5.x に変更したら、以前には出ていなかった警告が出ます A.
ARMCC5.x でのフロントエンドコンパイラ変更の影響で、以前には出ていなかった警告が出る場合があります。 例を挙げると、以下のような警告が出る場合があります。
|
45.
Q. コンパイラを ARMCC5.x に変更したら、--gnu 未指定時に #3093 のエラーになります A.
コンパイラは、--gnu モードが指定された場合、またはソースコード中に "#pragma anon_unions" が
しかしながら、以前はこれらの2つのオプションが使用されていない場合においても、 不正なコードの生成の原因となるため、ARMCC5.x ではエラーを出力するように修正しています。 |
46.
Q. ARMCC5.04 に変更したら、DLL モジュールのリンク時に L6244E のエラーになります A. ARMCC 5.04 のリンカでは、ダイナミックリロケーションが生成された場合、--no_legacyalign が デフォルトとなるように仕様を変更しています。
CTR-SDK のビルドシステムは、この仕様変更に対応していないため、DLL モジュールのリンク時に L6244E のエラーが発生します。
将来的には CTR-SDK での対応を予定していますが、現状は DLL アプリ / モジュールのリンク時には、 VSI-CTR Platform 2.3.4 以降では、ARMCC5.04 以降の --no_force-dynamic-natural-alignment オプション指定に対応しています。 |
47.
Q. ビルド時間を短縮する方法について A. ビルド時間を短縮する方法として、以下のような方法が考えられます。 1.ビルド時間全体に影響する方法
- 並列実行を活用する
- ビルド環境に十分なメモリを実装する
- ビルドで使用するファイルを高速なディスクに配置する
2.コンパイル時間に影響する方法
- ヘッダファイル検索順を調整する
- プリコンパイルヘッダを使用する
- 不要なデバッグ情報を出力しない
- コンパイル単位をまとめる 3.リンク時間に影響する方法
- マップファイルとコールグラフを生成しない
- 逆アセンブルリストを生成しない
- 入力オブジェクトファイルのデバッグ情報を減らす
- DLL アプリ・モジュールの部分リンク時にデバッグ情報を出力しない
CTR-SDK 7.2.1 以降で、DLL の部分リンク時にはデバッグ情報を作成しないように対応しました。 |
48.
Q. マップファイルを生成しない方法について A.
SDK のデフォルトのビルドルールでは、以下のオプションで指定した情報を、--list オプションで指定するファイル(.map) --info, --map, --symbols, --verbose, --xref
上記のオプションを指定しないようにしたうえで、--list オプションを指定しないことで、コンソールに出力される情報を SDK のビルドルールでは、ビルド変数 LDFLAGS_INFO を変更してください。 |
49.
Q. ARMCC5.04 に変更したら、デバッガが誤動作を起こします A.
ARMCC 5.04 では、デバッガが参照する出力ファイル(.axf ファイル)内の情報に変更がありました。
ARMCC 5.04 で作成したアプリケーションをデバッグするには、PARTNER-CTR 5.70-040(2014/01/23 版)以降を使用してください。 |