Compiling a custom malloc

Question

I have written a custom library which implements malloc/calloc/realloc/free using the standard C prototypes, and I figured out how to compile it to an so. I want to test the library by linking a standard application against it? What would be a good way to do this? Once I have a working library I assume I can just load it with LD_PRELOAD, but how do I get my functions to co-exist with but take precedence over the system library ones? My functions need to make a call to malloc in order to get memory to run, so I can't just completely ditch stdlib... Help?

Fleur

I am fairly sure that my answer lies in usage of the dynamic linker. – Fleur

Answer 1

Functions that you are trying to replace are standard C functions, not macros, not system calls. So you have to simply give your functions the same names and compile them into a shared library.

Then, use LD_PRELOAD to pre-load your library before binary starts. Since all addresses are resolved once, linker will figure out addresses of your functions and remember their names and will not look for them in standard library later.

This approach might not work if your program is linked with the standard runtime statically. Also, it will not work on Mac OS X as there is another API for interpolation.

In Linux, for example, in order for your functions to co-exist (i.e. if you want to use system malloc in your own implementation of malloc), you have to open the standard library manually using dlopen, look up functions you need there using dlsym and call them later by address.

Doublure

I thought I would run into more problems but after I removed inclusion of the standard library and loaded malloc and exit with dlsym everything compiled fine. Thanks! – Fleur

Answer 2

Don't write your malloc() in terms of malloc() -- write it using sbrk, which gets memory directly from the OS.

Manage

On some systems, sbrk() is not available anymore. For example, on my current Mac OS X, the man says The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management. and if you look the full source of the function, it's even funnier: errno = ENOMEM; return((void *)-1); – Minnieminnnie

Answer 3

If you have control of the source code that is to use this library, here is one possibility. Use different function names: Rather than malloc, for example, call it newCoolMalloc. This method is sometimes simpler and doesn't depend on special linker options.

Then in your code, use #define to cause the code to call the desired set of functions. You can #define malloc to be something different. For example:

#define malloc newCoolMalloc
#define free   newCoolFree

If you do that, though, you have to be very very careful to include that consistently. Otherwise you run the risk of using stdlib malloc in one place and then your own free in another leading to messy bugs. One way to help mitigate that situation is to (if possible) in your own code use custom names for the allocation and free functions. Then it is easier to ensure that the correct one is being called. You can define the various custom names to your own malloc functions or even the original stdlib malloc functions.

For example, you might use mallocPlaceHolder as the actual name in the code:

someThing = mallocPlaceHolder( nbytes );

Then your defines would look more like this:

#define mallocPlaceHolder myCoolMalloc

If no function of the form mallocPlaceHolder (and associated free) actually exist, it avoids mixing different libraries.

Hortatory

Unfortunately this doesn't work for me. I want to test my allocator by running somebody else's application using this library. I could recompile with those includes in theory, but time and effort will be saved with LD_PRELOAD. – Fleur