How to resolve naming conflicts when multiply instantiating 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 the C program defines global variables (which are intended for use by a specific instance of that program) which conflict in the global namespace. I would like to make minimal changes to the program in order to make this work. All ideas welcomed!

Regards

By the way ... This isn't a good time to mention that global variables are not best practice!

From stackoverflow

• The easiest thing to do would be to use task Variables (see taskVarLib documentation).

  When using task variables, the variable is specific to the task now in context. On a context switch, the current variable is stored and the variable for the new task is loaded.

  The caveat is that a task variable can only be a 32-bit number. Each global variable must also be added independently (via its own call to taskVarAdd?) and it also adds time to the context switch.

  Also, you would NOT be able to share the global variable with other tasks.
  You can't use task variables with ISRs.

• Another possible solution would be to put your application's global variables 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;
  }
  

  This simply turns into a search & replace in your application code. No change to the structure of the code.

• I had to solve this when integrating two third-party libraries from the same vendor. Both libraries used some of the same symbol names, but they were not compatible with each other. Because these were coming from a vendor, we couldn't afford to search & replace. And task variables were not applicable either since (a) the two libs might be called from the same task and (b) some of the dupe symbols were functions.

  Assume we have app1 and app2, linked, respectively, to lib1 and lib2. Both libs define the same symbols so must be hidden from each other.

  Fortunately (if you're using GNU tools) objcopy allows you to change the type of a variable after linking.

  Here's a sketch of the solution, you'll have to modify it for your needs.

  First, perform a partial link for app1 to bind it to lib1. Here, I'm assuming that you've already partially linked *.o in app1 into app1_tmp1.o.

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

  Then, hide all of the symbols from lib1 in the tmp2 object you just created to generate the "real" object for app1.

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

  Repeat this for app2. Now you have app1.o and app2.o ready to link into your final application without any conflicts.

  The drawback of this solution is that you don't have access to any of these symbols from the host shell. To get around this, you can temporarily turn off the symbol hiding for one or the other of the libraries for debugging.

• Another Possibility:
  If you are using Vxworks 6.x, you can make a Real Time Process application.
  This follows a process model (similar to Unix/Windows) where each instance of your program has it's own global memory space, independent of any other instance.