How to Resolve Name Conflicts on Multiple Instances of a Program in VxWorks
I need to run multiple instances of a C program in VxWorks (VxWorks has a global namespace). The problem is that a C program defines global variables (which are intended to be used by a specific instance of that program) that conflict in the global namespace. I would like to make minimal changes to the program to make this work. Any ideas are appreciated!
Hello
By the way ... Not a good time to mention that globals are not best practice!
source to share
The easiest would be to use task variables (see taskVarLib documentation).
When using task variables, the variable is specific to the task in the context. When the context switches, the current variable is saved and the variable is loaded for the new task.
The caveat is that the task variable can only be a 32-bit number. Each global variable must also be added independently (via its own call to taskVarAdd?) And also adds time to the context switch.
Also, you won't be able to share a global variable with other tasks.
You cannot use variable tasks with ISRs.
source to share
Another possible solution is to place your application globals in a static structure. For example:
From:
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;
}
It just turns into a search and replaces the application code. No changes in the structure of the code.
source to share
I had to solve this problem while integrating two third party libraries from the same vendor. Both libraries used the same symbol names, but they were not compatible with each other. Since they came from a supplier, we couldn't afford to search and replace. And task variables are not applicable since (a) two libraries can be called from one task and (b) some of the cheat symbols were functions.
Suppose we have app1 and app2 associated with lib1 and lib2, respectively. Both libs define the same symbols, so they must be hidden from each other.
Fortunately (if you are using the GNU tools) objcopy allows you to change the type of a variable after binding.
In this solution sketch, you will have to modify it to suit your needs.
First follow the partial link for app1 to link to lib1. Here I am assuming you have already partially linked * .o in app1 to app1_tmp1.o.
$(LD_PARTIAL) $(LDFLAGS) -Wl,-i -o app1_tmp2.o app1_tmp1.o $(APP1_LIBS)
Then hide all symbols from lib1 in the newly created tmp2 object to create a "real" object for the application.
objcopymips `nmmips $(APP1_LIBS) | grep ' [DRT] ' | sed -e's/^[0-9A-Fa-f]* [DRT] /-L /'` app1_tmp2.o app1.o
Repeat this for app2. You now have app1.o and app2.o ready to connect to your final application without any conflicts.
The downside to this solution is that you cannot access any of these characters from the host shell. To work around this, you can temporarily disable the hidden symbol for one or the other debugging libraries.
source to share