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 

윈드 리버 지원하기 위해 솔루션을 제공 new 및 delete 연산자가 오버로드되는 소스 파일의 다음 선언. 이것은 새로운/del 연산자의 라이브러리 버전을 생략하기 위해 컴파일러/링커에 신호를 보낸다.

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

이 작업을 수행 할 때도 위와 같이 동일한 다중 정의 오류가 발생하며 WindRiver 지원에는 현존하는 제안이 없습니다. 누구든지 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를 만들면 괜찮습니다. 다른 단계를 건너 뛸 수 있습니다.
5. 그렇지 않으면 objcopy --redefine-sym operatorName__WithMangling=operatorNameOriginal__WithMangling objFile.o을 실행하십시오. 나는 순수한 C 함수로 그렇게 했으므로 mangling이 없었지만, mangling이 큰 장애물이되지는 않을 것이라고 확신합니다. 다시 lib 디렉토리에
6. 넣어 수정 OBJ 파일 :
7. ar rvs libgnucplus.a objFile1.o objFile2.o ...는 접근 방식은 매우 더럽습니다, 나는 부정하지 않는 재미

을하고 몇 가지 단점이있다. 예를 들어 수정 된 툴체인은 업그레이드가 모든 동일한 단계를 다시 수행해야한다는 것을 의미합니다. 다른 하나는 (오래 지속되는 프로젝트에서 드문 상황이 아닌) 상황을 알지 못하는 개발자는 세부 사항을 파악하는 데 정말로 힘든 시간을 가질 것입니다. 제 경우에는 메모리 문제를 임시로 디버깅하는 데 사용되었으므로 도덕적 인 측면이 필요하지 않습니다.