Как перегрузить новые/удалить операторы в VxWorks 7 с помощью компилятора Gnu

Question

Я пытаюсь создать проект VxWorks7 Image Project (VIP), который включает мое приложение, которое перегружает новые и удаляет. Когда я создаю VIP и приложение отдельно с приложением в качестве загружаемого модуля ядра (DKM), он строит и работает нормально, загружая VIP в цель и загружая приложение DKM отдельно с помощью Workbench4. Однако, если я пытаюсь построить VIP и DKM вместе как единый загрузочный VIP я получить несколько определить ошибки для новых и удалять операторов из Workbench во время сборки следующим образом:

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-операторов.

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 не было никаких жизнеспособных предложений. Кто-нибудь испытывал опыт перегрузки global :: new и :: delete в VxWorks7 с использованием компилятора Gnu?

Это ссылка на вопрос о поддержке WindRiver 66370. Не уверен, что у него есть открытый доступ.

Answer 1

Оказывает множественное определение после попытки предлагаемого обходного пути Wind River из-за библиотек с круговыми ссылками, а также из-за использования обходного пути, указывающего все перегрузки, когда использовались только некоторые из них. Теперь я могу строить без проблем, используя следующие и не прибегая к модифицированной стандартной библиотеке, которую мы использовали ранее с 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. Список символов в объектах, компоновщик жаловался (_x_gnu_delaop.o, _x_gnu_delop.o и т. Д.), Используя nm objectName.o. Найти имена операторов, у них будет name mangling
4. Если объекты ничего не экспортируют, за исключением нежелательных операторов, и вы не хотите сохранять оригинальную реализацию, должно быть хорошо создать libgnucplus.a из всех файлов obj, кроме этих, так что вы может пропустить другие этапы
5. Иначе запустить objcopy --redefine-sym operatorName__WithMangling=operatorNameOriginal__WithMangling objFile.o. Я делал это на чистых функциях C, поэтому не было никаких искажений, но я уверен, что искажение не будет большим препятствием.
6. Помещенные модифицирована OBJ файлы обратно в Lib: ar rvs libgnucplus.a objFile1.o objFile2.o ...
7. Веселитесь

Я не отрицаю, что такой подход является довольно грязным и имеют некоторые недостатки. Например, модифицированная toolchain подразумевает, что ее обновление потребует повторного выполнения всех тех же шагов; другой заключается в том, что разработчик, не осознающий ситуацию (которая не является редкой ситуацией в долгосрочных проектах), будет очень трудно определить детали. В моем случае это использовалось для временных проблем с отладочной памятью, поэтому не было связанных с ней моральных аспектов :)