I'm a bit new to Linux systems programming. I've been programming at the systems level for over 20 years on various other platforms, but I'm not as familiar with the GCC toolchain as I'd like to be (but I'm learning quickly)...;)...
Our target is an ARM-based Linux Embedded system. We're using NPTL in most processes.
When using GCC to build shared libraries composed of multiple objects does each .o file have to be compiled with Position Independent Code options, or is it ok to simply invoke GCC during the final stage to compile/link and combine all the objects together specifying Position Independent Code options at that time along with the -shared option as well?
The reason I ask is I'm doing Remote GDB debugging on an embedded target, and I'm dynamically loading a shared library from my process via dlopen(), getting a function entry point with dlsym() and then indirectly invoking the function in the shared library. Under the above build scenario when I look at the resultant disassembly, say in a call to memset(), it simply loads an immedate offset for the target of the memset(), and this traps. Coincidently, the offset value is the same value assigned to the symbol when I dump the library with OBJDUMP. If I examine the target address passed to memset() the debugger doesn't appear to be able to access this address (no doubt why it traps). If I compile all objects with PIC options prior to the final stage above than the assembly code looks like it calculates the target address before calling memset(), and it doesn't trap.
In reading the GCC documentation it mentions the GOT, and from the above it appears that the loader isn't properly fixing up the symbol in question when each individual object isn't compiled with PIC options.
It was difficult enough getting the remote GDB environment set up to properly debug symbolically under a threaded dynamically loaded library scenario, so I've gotta' ask "Is this just an artifact of this type of symbolic debugging?"
The reason I say this is that our whole build system is setup to produce all the shared libraries we've written in this manner and no other team members have reported any issues running without a debugger (most of them don't use a debugger at all). All programs that run against these libraries are linked against the shared libraries, they are not performing dlopen() calls to access them like I am. The build system has been set up by an experienced Linux Systems Administrator.
I'm trying to get to the bottom of this. If anyone knows anything about this I'd appreciate their input.
Thanks in advance.