Gnuコンパイラを使用してVxWorks 7の新規/削除演算子をオーバーロードする方法

Question

新しいアプリケーションをオーバーロードし、削除するアプリケーションを含むVxWorks7イメージプロジェクト（VIP）を作成しようとしています。私は、ダウンロード可能なカーネルモジュール（DKM）としてVIPとアプリケーションを別々にビルドすると、ターゲット上のVIPを起動し、Workbench4でApp DKMを個別にダウンロードすることで、うまく構築されて実行されます。しかし、私は、私は複数の新規のためのエラーを定義し、以下のように、ビルド時にワークベンチから演算子を削除し得る単一のブート可能なVIPとして一緒にVIPとDKMを構築しようとした場合：

C:/BW/Vehicle/builds/cx20X0Up32BitDebugVsb/krnl/gnu_standard\libgnucplus.a(_x_gnu_delaop.o): In function `operator delete[](void*)': 
(.text+0x0): multiple definition of `operator delete[](void*)' 
C:/BW/Vehicle/builds/Vehicle/cx20X0Up32BitDebugVsb_SANDYBRIDGEgnu/Vehicle_partialImage/Debug/Vehicle_partialImage.o:C:/BW/Alcatraz/Vehicle/src/IRL/Util/heap.cpp:886: first defined here 
C:/BW/Vehicle/builds/cx20X0Up32BitDebugVsb/krnl/gnu_standard\libgnucplus.a(_x_gnu_delop.o): In function `operator delete(void*)': 
(.text+0x0): multiple definition of `operator delete(void*)' 
C:/BW/Vehicle/builds/Vehicle/cx20X0Up32BitDebugVsb_SANDYBRIDGEgnu/Vehicle_partialImage/Debug/Vehicle_partialImage.o:C:/BW/Alcatraz/Vehicle/src/IRL/Util/heap.cpp:841: first defined here 
C:/BW/Vehicle/builds/cx20X0Up32BitDebugVsb/krnl/gnu_standard\libgnucplus.a(_x_gnu_newaop.o): In function `operator new[](unsigned int)': 
(.text+0x0): multiple definition of `operator new[](unsigned int)' 
C:/BW/Vehicle/builds/Vehicle/cx20X0Up32BitDebugVsb_SANDYBRIDGEgnu/Vehicle_partialImage/Debug/Vehicle_partialImage.o:C:/BW/Alcatraz/Vehicle/src/IRL/Util/heap.cpp:813: first defined here 
C:/BW/Vehicle/builds/cx20X0Up32BitDebugVsb/krnl/gnu_standard\libgnucplus.a(_x_gnu_newop.o): In function `operator new(unsigned int)': 
(.text+0x0): multiple definition of `operator new(unsigned int)' 
C:/BW/Alcatraz/Vehicle/builds/Vehicle/cx20X0Up32BitDebugVsb_SANDYBRIDGEgnu/Vehicle_partialImage/Debug/Vehicle_partialImage.o:C:/BW/Alcatraz/Vehicle/src/IRL/Util/heap.cpp:808: first defined here 
collect2.exe: error: ld returned 1 exit status 

WinDriverのサポートを行うためにソリューションを提供新しい演算子と削除演算子がオーバーロードされるソースファイルの次の宣言。これは、新しい/ del演算子のライブラリ版を省略するようにコンパイラ/リンカに通知することになっています。この私はまだ、上記と同じ乗算定義されたエラーを取得し、WinDriverのサポートは任意の実行可能な提案を受けていないを行う

int ___x_gnu_newaop_o = 1; 
int ___x_gnu_newop_o = 1; 
int ___x_gnu_delaop_o = 1 ; 
int ___x_gnu_delop_o = 1; 

。誰もがGnuコンパイラを使ってVxWorks7でglobal :: newと:: deleteをオーバーロードしようとした経験がありましたか？

ここはWindRiver Support 66370の問題へのリンクです。パブリックアクセスが可能かどうかは不明です。

Answer 1

ウインドリバー提案回避策をしようとすると、循環参照とライブラリによるものであったとも指定する回避策を使用してから、後に複数の定義が判明一部のみが使用されたときはすべてオーバーロードされます。私は今、VxWorks 6で以前に使用していた標準ライブラリを変更せずに、以下のコードを使用して問題なくビルドすることができます。x：

// ======== SPECIAL CASE NEW/DELETE OPERATOR OVERLOAD FOR GNU ======== 
// The following ___x_gnu_????.o global variable definitions are special 
// case indicators to Gnu compiler when building the application into an 
// integrated VIP (VxWorks Image Project). They indicate which new and 
// delete operators are being overloaded. Doing this avoids a multiple 
// definition build error for new/delete operators. This multiple 
// definition error is only an issue when building application as an 
// integrated VIP and not when app is downloaded separate from VIP as a 
// Downloadable Kernel Module (DKM). It is important to only include 
// ___x_gnu_????_o variables for the specific operators being 
// overloaded. Defining a ___x_gnu_????_o variable for an operator that 
// is not actually overloaded will cause a multiple define error also. 
// This solution to overloading new/delete was obtained directly from 
// Wind River support and is described in case #66370 and as of this 
// date is not described anywhere in Wind River documentation. 
// link to case #66370 below. -- 2017Jan18jdn 
// 
// https://windriver.force.com/support/apex/CaseReadOnly?id=5001600000xKkTYAA0 
int ___x_gnu_newaop_o = 1;  // Indicates overload of new [] operator 
int ___x_gnu_newop_o = 1;  // Indicates overload of new operator 
int ___x_gnu_delaop_o = 1 ;  // Indicates overload of delete [] operator 
int ___x_gnu_delop_o = 1;  // Indicates overload of delete operator 

Answer 2

私はデバッグの目的でmalloc/free関数を再定義して同様の状況に陥りました。おそらく、私のソリューションは粗末ですが、単純で効率的です。標準関数を "malloc_original"と "free_original"に変更しました。したがって、mallocとfreeの呼び出しはすべて新しい実装にのみ関連していましたが、mallocとfreeの新しいバージョンでは必要に応じて元の機能が呼び出されていました。方法は次のとおりです。

1. 元の機能を持つライブラリを探します。あなたの場合はlibgnucplus.a
2. ライブラリは単なるオブジェクトのアーカイブです。 ar -x libgnucplus.a
3. nm objectName.oを使用して、リンカーが（_x_gnu_delaop.o、_x_gnu_delop.oなど）について不平を言っていたオブジェクトのシンボルをリストします。演算子の名前を見つけて、それらはいくつか持っていますname mangling
4. オブジェクトが望ましくない演算子を除いて何もエクスポートせず、元の実装を保ちたくない場合は、これら以外のすべてのobjファイルからlibgnucplus.aを作成することはOKです。他の手順をスキップできます
5. それ以外の場合はobjcopy --redefine-sym operatorName__WithMangling=operatorNameOriginal__WithMangling objFile.oを実行してください。私は純粋なC言語の関数で行いました。だからmanglingはありませんでしたが、私は確信しています、manglingは大きな障害ではありません。
6. objが背中のlibにファイル変更のPut：ar rvs libgnucplus.a objFile1.o objFile2.o ...
7. は楽しい

を持って、私は否定しないが、そのアプローチはかなり汚れていると、いくつかの欠点を持っています。たとえば、変更されたツールチェーンが意味することは、アップグレードには同じ手順をすべてやり直す必要があるということです。もう1つは、状況を認識していない開発者（長期にわたるプロジェクトではまれな状況ではない）が、詳細を把握するのに非常に苦労することです。私の場合、それは一時的なデバッグメモリのトラブルのために使用された、関係ありませんので、道徳的な側面:)