Duplicate symbol names in shared library

[cerealito]

Hi everyone; I have a Linux/C programming question, and although it is not gentoo-specific, I was hoping that you could shed some light into my life.

We have this strange prototype at work which is based upon an avionics simulator, written in C and running on Linux. The original simulator provides all the functionality of the avionics operating system and gives the avionics applications access to the system through an API. Each individual application is loaded in memory as a shared object using dlopen().

Now, the prototype, which adds certain features to the original simulator, is to be used as a testing platform of some software functions used by the aircraft. For the sake of the test, some operating system calls are to be controlled in a "deterministic" way, thus redefining these O.S. functions in the loaded application.

The problem with this is, that the shared-object of the application contains symbols with the same name and signature as some system functions in the simulator. In spite of my experiments using LD_PRELOAD and different flags on dlopen, I always get the simulator functions to execute instead of those in the shared object (the application). Because there are a couple hundreds of tests redefining different symbols each time, recompiling the simulator is not an option.

Here is an example of the problem:
main.c: the simulator code, it has the "real" OS system functions.

Code: Select all

#include <stdio.h>
#include <dlfcn.h>

void duplicate() {
	printf("This is the first (hard coded) function\n");
}

int main() {
	dlopen("appTest.so",RTLD_NOW|RTLD_LOCAL); //flags do not seem to change the behavior
	duplicate();
	return 0;
}

appTest.c: the application code, redefines a symbol:

Code: Select all

#include <stdio.h>
void duplicate() {
	printf("this is the Application dynamic library!!! :)\n");
}

compilation and results

Code: Select all

$ gcc -Wall -shared appTest.c -o appTest.so
$ gcc -Wall main.c -ldl
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.
$ export LD_PRELOAD=appTest.so
$ ./a.out
This is the first (hard coded) function

Why isn't LD_PRELOAD working? Am I missing something here? How can I force a program to execute the code on a loaded shared library instead of that in his own code? I supose that this is the normal, expected way of Linux to behave (being able to "overwrite" code being executed would have important security issues). I've red of a dlopen flag called DEEP_BIND in recent glibc versions, but I'm not sure if that's what I need and I wanted to ask here first.

Any explanation/help/suggestion will be greatly appreciated....

(I'm using gcc (GCC) 3.4.4 20050721 and Linux 2.6.9-22.ELsmp)

Cheers!

[ricce_n]

Take a handle from dlopen:

Code: Select all

int main(int argc, char **argv) {
void *handle;
void (*pduplicate)(void);
handle = dlopen("appTest.so",RTLD_NOW|RTLD_LOCAL);
pduplicate = dlsym(handle, "duplicate");
if(pduplicate) pduplicate();
else ;// the symbol `duplicate' dose not exist in appTest.so or is NULL.
}

[cerealito]

ricce_n, thanks a lot for your reply.
I had not thought about that before. Indeed, that works, and I am definitely considering it as an option now. However, I would like to continue searching for a "solution" that would not imply (big) modifications to the simulator code because the api is quite big in number of functions and I do not know which applications redefine the functions of the api (not all applications redefine the same ones, if at all).

thank you anyways, I've already learned something new!. If you have any other clue please let me know!

[didl]

I don't know your project at all and how mission critical it
is but I'd say that if you want it to be a robust application
then remove these duplicate symbols and don't rely on
the loader and other magic to find the proper symbols, since
otherwise your app will likely crash badly.
Even if it may be a lot of work to fix the code, in the long
run it will pay off big time and your application may actually
run.

[Gergan Penkov]

I don't think that LD_LIBRARY_PRELOAD could redefine the internal symbols, does the same happen, if you have the both definitions of these functions exported from shared objects and link your main application to one of them.
And as didl said, LD_LIBRARY_PRELOAD is an ugly hack for misbehaving apps or debuging and should not be used at all in production.