I would like to replace the default malloc at link time to use a custom malloc. But when I try to redefine malloc in my program, I get this error:
MSVCRT.lib(MSVCR80.dll) : error LNK2005: _malloc already defined in test.lib(test.obj)
This works perfectly on any Unix, and it works on Windows with most functions, but not with malloc. How can I do this? And what is different with malloc that disallow overriding it?
I know I could replace every call to malloc with my custom malloc, or use a macro to do this, but I would rather not modify every third party library.
There is really good discussion of how hard this is here:
http://benjamin.smedbergs.us/blog/2008-01-10/patching-the-windows-crt/
Apparently, you need to patch the CRT
Edit: actually, a MS employee gave the technique in the discussion. You need to move your malloc to a lib, and then link it before the CRT
"he also mentions that if you link your malloc as a lib before the CRT (i.e. make sure to turn on ‘ignore default libs’ and explictly include the CRT), you’ll get what you want, and can redistribute this lib without problems."
I think it depends in which order you link the files. I think you need to link your custom function first, then the import library.
From version 3.0 Firefox uses a custom allocator (AFAIR jmalloc) -- you could check how they did it. I read that they had some problems with it. You may check this blog post.
What about defining malloc=_custom_malloc in the project makefile.
Than adding a file such as:
my_memory.c
#undef malloc
#undef calloc
...
void *_custom_malloc(int size) { return jmalloc(size); }
void *_custom_calloc(int size) { return jcalloc(size); }
...
Related
I have the following issue/question:
I'm currently working on visual studio in C
I made a program that uses the functions malloc and free, I am sure I used them well, but when I try to compile I get the following errors:
Error C3861 'free': identifier not found
Error (active) identifier "free" is undefined
(same errors for malloc)
the only include statement I made was for stdio.h (which I usually add and it works fine for these functions)
I added stdlib and the problem was resolved, but when I serve this chore I may be downgraded for including a library we did not work with so far, can anyone tell me why the functions don't work with just stdio.h?
<stdlib.h> is the correct header to include when calling malloc and free. In fact, it's correct to say that you must include <stdlib.h> (directly or indirectly) when calling malloc and free.
There are lots of reasons why it might have worked for you once before even though you didn't. Without seeing that older code, I couldn't say why. Don't worry about it. Just always include <stdlib.h> when calling malloc and free.
Malloc and free is defined under stdlib.h. So without including it your program wont work.
I'm using LPCXpresso with LPC1768. I'm trying to implement few memory pools. I have my old code that allows this, so I'm fine there. What I'm unable to do is to prevent newlib from using it's own malloc. There are few functions in newlib calling malloc. I dodged them all, except for _Csys_alloc, which is unfortunately called by _initio. Since malloc isn't weak, I can't simply replace it with my own implementation. So is there any other way to do it except for either modifying newlib and recompiling or writing my own _initio routine?
Thanks for your help.
It is perhaps simplest to let Newlib use its malloc as it wants and implement _sbrk() to limit its use and location to a static pool sized to just what is needed for library initialisation, then override malloc() for use in your own code - the linker will only link to standard library symbols if not previously found in another library of object code.
I need to recode the free() func for educational purpose and it must be named free() also.
When i rename my function myfree() it work flawlessly but when i name it free() the program don't know if he need to use mine or the system's so the program just Segmentation fault(core dumped) even if i don't call my free (just the declaration of another free() func seem to crash it)
so how can i tell the compiler to use mine instead of the system's ?
thanks you in advance.
EDIT : Linux operating system
Basically, you have three options that I can see
Redirect it during compile time, for example using #define as #Mohamed suggests.
Change it at runtime using LD_PRELOAD.
Modify the existing malloc/free using malloc hooks.
If you're using GCC, you can use the compiler to help you. When you compile, include this on your link line: -Xlinker --wrap=free. This will redirect all calls to free() to use __wrap_free(), which you must provide. If you wish to call the original free() function, it's still there but renamed; you can call __real_free().
This will capture pre-compiled libraries you link against, something a macro cannot do (but LD_PRELOAD can).
use macros for that: to force program to use your myfree() function:
#define free(X) myfree(X)
The easiest (not the safest) way is to #define free myfree so the preprocessor will replace all calls from free() to myfree(). Another, more safe approach, would be create a normal function called free() and do not include libraries, that also contain free() function.
If you are looking for a standard way, I'm afraid it doesn't exist. Redefining standard library names is undefined behavior.
C11, 7.1.3.2:
... If the program declares or defines an identifier in a
context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved
identifier as a macro name, the behavior is undefined.
In 7.1.4, there are is a long explanation of how the library may define a macro with the same name as the function and how to bypass that macro. There is no indication of how a user may override a standard library function.
You can also see this question for more information.
Non standard ways are of course always possible as you can find in other answers.
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?
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.
Don't write your malloc() in terms of malloc() -- write it using sbrk, which gets memory directly from the OS.
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.
I would like to trace calls to some 3rd party library which are made from another 3rd party library.
Example: I want to trace calls to library A. My application statically links library B, which in turn is statically linked to library A. So basically what I have is libAB.a
In case of dynamic linking I could write library A2 with wrappers for functions which I want to trace of library A and use LD_PRELOAD=A2.so. Then, my wrappers will be called instead, and I will see the trace.
In my case I cannot use dynamic linking.
Is it possible to achieve the same using static linking?
In ideal case I would like to link my application with libAB.a and trace library libA2.a and get the trace.
Thanks,
Robusta
Okay, I found it :)
man ld
--wrap symbol
Use a wrapper function for symbol. Any undefined reference to symbol will be resolved to "__wrap_symbol". Any undefined ref‐
erence to "__real_symbol" will be resolved to symbol.
This can be used to provide a wrapper for a system function. The wrapper function should be called "__wrap_symbol". If it
wishes to call the system function, it should call "__real_symbol".
Here is a trivial example:
void *
__wrap_malloc (size_t c)
{
printf ("malloc called with %zu\n", c);
return __real_malloc (c);
}
If you link other code with this file using --wrap malloc, then all calls to "malloc" will call the function "__wrap_malloc"
instead. The call to "__real_malloc" in "__wrap_malloc" will call the real "malloc" function.
Depending on how much performance matters you could do it with gdb... (Set a breakpoint on all the functions you care about and log the stack traces... but that involves learning how to script gdb)
There's also things like Oprofile http://oprofile.sourceforge.net/, LTTng http://lttng.org/, and perf (comes with recent kernels in the kernel source it's under tools/perf/ you need to compile it, on Ubuntu I think it's in the linux-tools package)
I can't tell you how to achieve what you want with any of those tools but oprofile and LTTng have lots of documentation and an active user community.
Well, it seems like a dead lock :)
But I think you may solve it using macros. Although this solution might not be clean and may not work for all situations.
You can try this:
void functionFromLibA();
#define functionFromLibA() trace(); functionFromLibA()
int main()
{
functionFromLibA();
}
This will be expanded to:
void myfunc();
int main()
{
trace(); functionFromLibA();
}
EDIT: But note that for this solution, all declarations of functions prototypes should be done before defining the macros. Else you will have the prototypes expanded in preprocessing as well.