Custom malloc compilation

Question

I wrote a special library that implements malloc / calloc / realloc / free using standard C prototypes, and I figured out how to compile it. I want to test a library by associating a standard application with it? What would be a good way to do this? As soon as I have a working library, I assume that I can just load it with LD_PRELOAD, but how do I make my functions coexist with them, but have an advantage over system libraries? My functions need to call malloc to get memory to run, so I can't just stop stdlib completely ... Help?

Answer 1

The functions you are trying to replace are standard C functions, not macros, not system calls. Therefore, you just need to give your functions the same names and compile them into a shared library.

Then use LD_PRELOAD to preload the library before running the binaries. Since all addresses are resolved once, the linker will determine the addresses of your functions and remember their names and will not look for them in the standard library later.

This approach may not work if your program is statically linked to standard runtime. In addition, it will not work on Mac OS X, as there is another API for interpolation.

On Linux, for example, so that your functions coexist (i.e. if you want to use the malloc system in your own malloc implementation), you need to open the standard library manually using dlopen , find the necessary functions using dlsym , and call them later at .

Answer 2

Do not write malloc() in terms of malloc() - write it using sbrk , which receives memory directly from the OS.

Answer 3

If you have control over the source code that this library should use, here is one of the possibilities. Use different function names: instead of malloc, for example, name it newCoolMalloc. This method is sometimes simpler and independent of special linker options.

Then in your code use #define to call the code to invoke the desired set of functions. You can #define malloc be something else. For instance:

 #define malloc newCoolMalloc #define free newCoolFree 

If you do this, you have to be very careful to enable it consistently. Otherwise, you run the risk of using stdlib malloc in one place, and then your own free in another, leading to erratic errors. One way to help alleviate this situation (if possible) in your own code is using custom names for distribution and free features. Then it is easier to ensure that the correct one is called. You can define different user names for your own malloc functions or even for the original stdlib malloc functions.

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

 someThing = mallocPlaceHolder( nbytes ); 

Then your definitions will look something like this:

 #define mallocPlaceHolder myCoolMalloc 

If the mallocPlaceHolder function (and its associated one is free) does not actually exist, it avoids mixing different libraries.