The question of overriding the standard C library functions and how to bundle everything together

I made my own implementation of _init, malloc, free (and others).

Inside these functions, I use the dlfcn.h library (dlopen, dlsym, etc.) to call real standard versions. I put it in a single file and compiled them as a shared library (memory.so). When I want to run the executable and make it call my versions of these functions, I simply set LD_PRELOAD = memory.so.

The problem is that I have a number of other modules that memory.c depends on. These include a file containing functions for scanning elf files (symbol.c) and my own implementation of the hash table (hashtable.c), which I use to track memory leaks among others.

My question is, is there a way to separately compile hashtable.c and symbols.c, so any malloc links are resolved using the standard library, and not those included in .c memory. I could, of course, use the dlfcn.h libraries in everything that depends on memory.c, but I would prefer that there be a way to avoid this.

I still do not quite understand how the links work, so any help would be appreciated.

thanks

+4
source share
3 answers

If you are working with glibc, you can use alternative names without overriding functions:

[ max@truth ~]$ nm --defined-only --dynamic /lib64/libc.so.6 | egrep "malloc\b" 0000003e56079540 T __libc_malloc 0000003e56079540 T malloc 

Pay attention to the same function address above. In other words, the malloc() function is defined by two names, so the original version of malloc() is available under the name __libc_malloc() if malloc() was inserted.

A quick grep for glibc sources shows that the only caller of __libc_malloc() is mcheck . These function aliases are part of the glibc implementation, and there is no header for them. malloc / mcheck.c declares internal functions as shown below:

 extern __typeof (malloc) __libc_malloc; extern __typeof (free) __libc_free; extern __typeof (realloc) __libc_realloc; 

Other C libraries may have named aliases in different ways, so using dlsym() to get the original malloc() address is more portable.

+5
source

First, it’s important to note that there is no need to do what you want to do for memory debuggers in Linux, since glibc provides certain hook functions for memory functions (see http://www.gnu.org/s/libc/manual /html_node/Allocation-Debugging.html )

But, ignoring this, the general solution is to NOT use dlopen () to get the glibc link for dlsym (), but rather use the magic RTLD_NEXT handle. Here is the relevant part on the dlopen () user page:

"There are two special pseudo-descriptors: RTLD_DEFAULT and RTLD_NEXT. The first will find the first occurrence of the desired character using the default search order in the library. The latter will find the next occurrence of the function in the search order after the current library, which allows you to provide a wrapper around the function in another shared library." .

See for example: http://developers.sun.com/solaris/articles/lib_interposers_code.html

+3
source

You can take a look at the electric fence . It overrides many of the standard functions for debugging memory.

+1
source

Source: https://habr.com/ru/post/1342690/


All Articles