Using system symbol table from VxWorks RTP

Question

I have an existing project, originally implemented as a Vxworks 5.5 style kernel module.

This project creates many tasks that act as a "host" to run external code. We do something like this:

void loadAndRun(char* file, char* function)
{
    //load the module
    int fd = open (file, O_RDONLY,0644);
    loadModule(fdx, LOAD_ALL_SYMBOLS);

    SYM_TYPE type;
    FUNCPTR func;
    symFindByName(sysSymTbl, &function , (char**) &func, &type);

    while (true)
    { 
        func();
    }   
}

This all works a dream, however, the functions that get called are non-reentrant, with global data all over the place etc. We have a new requirement to be able to run multiple instances of these external modules, and my obvious first thought is to use vxworks RTP to provide memory isolation.

However, no matter what I try, I cannot persuade my new RTP project to compile and link.

error: 'sysSymTbl' undeclared (first use in this function)

If I add the correct include:

#include <sysSymTbl.h>

I get:

 error: sysSymTbl.h: No such file or directory

and if i just define it extern:

 extern SYMTAB_ID    sysSymTbl;

i get:

  error: undefined reference to `sysSymTbl'

I havent even begun to start trying to stitch in the actual module load code, at the moment I just want to get the symbol lookup working.

So, is the system symbol table accessible from VxWorks RTP applications? Can moduleLoad be used?

EDIT It appears that what I am trying to do is covered by the Application Programmers Guide in the section on Plugins (section 4.9 for V6.8) (thanks @nos), which is to use dlopen() etc. Like this:

 void * hdl=  dlopen("pathname",RTLD_NOW);
 FUNCPTR func = dlsym(hdl,"FunctionName");
 func();

However, i still end up in linker-hell, even when i specify -Xbind-lazy -non-static to the compiler.

undefined reference to `_rtld_dlopen'
undefined reference to `_rtld_dlsym'

Answer 1

The problem here was that the documentation says to specify -Xbind-lazy and -non-static as compiler options. However, these should actually be added to the linker options.

libc.so.1 for the appropriate build target is then required on the target to satisfy the run-time link requirements.