Originally Posted by
josymadamana
i am writing a memcpy wrapper. and i am doing a LD_PRELOAD of the library on which memcpy wrapper is written. Now if i run a application which calls strcpy it is not doing it fast. if i am runing the same application without LD_PRELOAD, it is running faster. but if i am running it with a preloaded library it is slow. even if it not defined in the library.
If the compiler knows the string length, it may be calling memcpy() instead of strcpy(), since the former is more efficient when the string length is already known. You could verify it by for example adding
Code:
write(STDERR_FILENO, ".", 1);
to your memcpy() wrapper, as that will try to output a . to standard error whenever memcpy() is called.
Originally Posted by
josymadamana
Will LD_PRELOAD will decrease the speed of execution??
Adding a new library to a program will increase the startup latency. It is very small, but measurable, at least on slow machines. This happens because loading the dynamic library file, and resolving its symbols, does take (a little bit) of CPU time.
By itself, the LD_PRELOADed library should only slow down the functions it interposes. (In addition to the startup load and initial symbol lookup latency I mentioned above.) It should not affect the rate you can call a non-interposed function in a tight loop, for example.
However, it is possible that the C library itself behaves differently when LD_PRELOAD is set.
One trick you might wish to try is to unset the LD_PRELOAD environment variable in your library init/constructor function [EDIT: use environ instead of unsetenv()]:
Code:
extern char **environ;
static void my_lib_init(void) __attribute__((constructor));
static void my_lib_init(void)
{
/* Find "LD_PRELOAD=" in the environ array, and remove it
* by replacing it with the final pointer in the array,
* and setting the final pointer to NULL.
*/
}
I am unsure whether it works, because it depends on whether the constructor gets executed before the C library constructor does. If this gets executed first, then it should stop the C library from behaving differently due to LD_PRELOAD being set.
If LD_PRELOAD being set causes the linker (dynamic library) to work in inefficient ways, then there is not much you can do about it.
Edit 2:
I wrote a trivial dynamic library that interposes only the open() syscall, then tested whether it affects other functions; a loop that copies the program name (argv[0]) from one buffer to another for one second wall clock time, and prints the number of iterations.
Loading the library actually yielded more iterations per second, rather than less. I suspect that is related to memory (stack) alignment or something similar, and has nothing to do with the LD_PRELOAD mechanism.
So, according to my quick observations, I cannot duplicate the LD_PRELOAD slowdown on unrelated functions.
