2

I have a legacy system which declares symbols in a shared memory region. The addresses of the are statically defined to absolute addresses in memory using gcc's linker command script function. I can build a static test executable in C which references these symbols correctly when I pass the static object file and linker command script during compilation, and attach to the shared memory region (shmat(), etc).

What I am trying to do is build a Python extension library which can access the same symbols. Being able to access the library from Python requires the -shared and -fPIC options from what I understand. When I compile this way, the symbols are no longer located at the correct addresses. Compiling the C test program with -shared -fPIC causes the addresses to be wrong as well. I can define the symbols within the extension library directly:

int *pA = 0x030A0000;

and this works when compiled using -shared -fPIC. But should I? There are hundreds of symbols I need and it would be unmaintainable if the addresses ever changed. It seems like there should be a way to indicate to the linker that these symbols should not be relocated, but nothing I have tried has worked, including compiling as below:

In the code for Python extension:

extern int symbol_i_need;
...
printf("%d", symbol_i_need); // Seg fault

Compile commands:

gcc -fPIC -o my_module.o my_module.c /path/static_object.o /path/linker_command_script.ld 
gcc -shared -fPIC -o my_module.so my_module.o -Wl,-Bstatic,/path/static_defined_object.o,/path/linker_command_script.ld,-Bdynamic -rdynamic
Community
  • 1
  • 1
Scott L.
  • 265
  • 2
  • 9
  • `PIC` stands for 'Position Independent Code' and indicates to the linker that it can take the function from the library and place it anywhere in the code section of memory. I may not be as swift as many others but other than what you're doing I don't really have a solution. – jiveturkey Apr 29 '15 at 20:12
  • Yes, I read the description for the flag in the man page and it raised some warning flags with me. However, I am using the distutils to build the Python module and the flag is inserted automatically. My assumption was that it was required for the module to work with Python correctly but I will do some investigating. – Scott L. Apr 29 '15 at 23:08

1 Answers1

0

After researching and much experimentation with various flags (--just-symbols, -Bsymbolic, --dynamic-list, --defsym, etc) and with the help of these answers and objdump and some printf's, I found that the way shared objects index their symbols prevent the result I was going for. It's really not feasible to compile the desired Python extension as a shared object without manually setting up pointers to all the symbols you need.

What I was able to do was add the same module code I had written to the built-in Python modules. Recompiling Python with my custom module there and linking against the static object file and linker command scripts I already had (added to the Modules/Setup file: my_module my_module.c -I/include/path -Xlinker /path/static_object.o /path/linker_script.ld) allowed all the symbols to resolve to their correct addresses. The documentation within the Python source was sufficient to show me how to do this.

Community
  • 1
  • 1
Scott L.
  • 265
  • 2
  • 9