Как разрешить конфликты имен при многократном создании программы в VxWorks

Question

Мне нужно запустить несколько экземпляров C-программы в VxWorks (VxWorks имеет глобальное пространство имен). Проблема в том, что программа на C определяет глобальные переменные (которые предназначены для использования конкретным экземпляром этой программы), которые конфликтуют в глобальном пространстве имен. Я хотел бы внести минимальные изменения в программу, чтобы сделать эту работу. Все идеи приветствуются!

Привет

Кстати ... Сейчас не время упоминать, что глобальные переменные - не лучшая практика!

Answer 1

Другая возможность:
Если вы используете Vxworks 6.x, вы можете создать приложение процесса реального времени.
Это следует модели процесса (аналогично Unix / Windows), где каждый экземпляр вашей программы имеет свое собственное глобальное пространство памяти, независимо от любого другого экземпляра.

Answer 2

Самое простое, что можно сделать, это использовать переменные задачи (см. Документацию taskVarLib).

При использовании переменных задачи переменная является специфичной для задачи, которая теперь находится в контексте. При переключении контекста текущая переменная сохраняется и загружается переменная для новой задачи.

Предостережение заключается в том, что переменная задачи может быть только 32-разрядным числом. Каждая глобальная переменная также должна быть добавлена ​​независимо (через собственный вызов taskVarAdd?), И это также добавляет время к переключению контекста.

Кроме того, вы НЕ сможете использовать глобальную переменную совместно с другими задачами.
Вы не можете использовать переменные задачи с ISR.

Answer 3

Мне пришлось решить эту проблему при интеграции двух сторонних библиотек от одного поставщика. Обе библиотеки использовали одни и те же имена символов, но они не были совместимы друг с другом. Поскольку они исходили от продавца, мы не могли позволить себе искать и заменять. И переменные задачи также не были применимы, так как (а) две библиотеки могли быть вызваны из одной и той же задачи и (б) некоторые символы дублирования были функциями.

Предположим, у нас есть app1 и app2, связанные соответственно с lib1 и lib2. Обе библиотеки определяют одинаковые символы, поэтому должны быть скрыты друг от друга.

К счастью (если вы используете инструменты GNU), objcopy позволяет вам изменять тип переменной после связывания.

Вот эскиз решения, вам придется изменить его для своих нужд.

Сначала выполните частичную ссылку для app1, чтобы связать ее с lib1. Здесь я предполагаю, что вы уже частично связали * .o в app1 с app1_tmp1.o.

    $(LD_PARTIAL) $(LDFLAGS) -Wl,-i -o app1_tmp2.o app1_tmp1.o $(APP1_LIBS)

Затем спрячьте все символы из lib1 в объекте tmp2, который вы только что создали, чтобы сгенерировать «настоящий» объект для app1.

    objcopymips `nmmips $(APP1_LIBS) | grep ' [DRT] ' | sed -e's/^[0-9A-Fa-f]* [DRT] /-L /'` app1_tmp2.o app1.o

Повторите это для app2. Теперь у вас есть app1.o и app2.o, готовые без каких-либо конфликтов связать ваше окончательное приложение.

Недостаток этого решения заключается в том, что у вас нет доступа ни к одному из этих символов из оболочки хоста. Чтобы обойти это, вы можете временно отключить скрытие символа для одной или другой библиотеки для отладки.

Answer 4

Другое возможное решение - поместить глобальные переменные вашего приложения в статическую структуру. Например:

От:

int global1;
int global2;

int someApp()
{
   global2 = global1 + 3;
   ...
}

TO:
typedef struct appGlobStruct {
  int global1;
  int global2;
} appGlob;

int someApp()
{
   appGlob.global2 = appGlob.global1 + 3;
}

Это просто превращается в поиск и замену в вашем коде приложения. Без изменений в структуре кода.