C.Praveen c_praveen at yahoo.com
Mon Jul 28 07:29:53 UTC 2014

Greetings! I'm having trouble using the LD_PRELOAD feature on MIPS when certain libraries are linked in. I'm hoping someone can provide some information on where I could start looking. The problem is best shown by the following code:

---------------------------- memc.c ----------------------------------

typedef void *(*memcpy_t) (void *dest, const void *src, size_t n);
void *memcpy(void *dest, const void *src, size_t n)
    memcpy_t res;
    void *out;

    res = dlsym(RTLD_NEXT, "memcpy");
    printf ("Calling memcpy indirect %p\n", res);
    out = res (dest, src, n);
    printf ("Done calling indirect \n");
    return out;

This is compiled as 

gcc -fPIC -c memc.c
gcc -shared -o memc.so memc.o -ldl

-------------------------- test.c -------------------------------------

void f (char *p)
char buff[62];

printf ("calling memcpy fn %p\n", memcpy);
memcpy(buff, p, 32);

printf ("Done memcpy fn\n");
int main(int argc, char **argv)
        char buff[64];



        return 0;

This is compiled as gcc test.c -lpthread

When I run it without LD_PRELOAD, it works as expected calling the "real" memcpy. 

When I run it as "LD_PRELOAD=memc.so ./a.out" I get a core dump with the backtrace pointing to dl_runtime_resolve

#0  0x2aaab334 in __dl_runtime_resolve () from
#1  0x2aaaf0fc in _dl_runtime_resolve ()

I suppose it is linked to runtime resolution of symbols? Things work as expected if the pthread library is not linked in. Some libraries cause core dumps when linked in and some don't (libresolv and libm don't while libpthread and libstdc++ do). I guess it has something to do with init functions of these libraries?

Any ideas of what I can do here or pointers to where I should start looking will be greatly appreciated. To repeat myself, it's on the MIPS platform

Thanks much for any help,

More information about the uClibc mailing list