8

I'm trying to implement a simple fit first memory management algorithm. So I've got a C file with my own 

   void* malloc(size_t)

and

   void free(void*)

When generating a .out file with gcc, I'm expecting a link error because it'll conflict with the existing standard implementation. But my file links fine.

Please help me to understand.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
lang2
  • 11,433
  • 18
  • 83
  • 133
  • I think it's considered acceptable practice to "override" routines in this way using link order so there is no link error/warning by default. – Paul R Jun 10 '13 at 09:22
  • 3
    It links, but does it actually run your code? GCC has malloc and free builtins that might override yours. – idoby Jun 10 '13 at 09:22
  • 4
    @IBY: good point - OP might need `-fno-builtin` or `-fno-builtin-malloc -fno-builtin-free` to ensure that his routines get called. – Paul R Jun 10 '13 at 09:23
  • Wouldn't [using a shared library](http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick) do the trick ? – DCMaxxx Jun 10 '13 at 09:25
  • 5
    So, which system are you on ? If this is on linux, then malloc/etc. in glibc are weak symbols, meaning you can override them with your own. – nos Jun 10 '13 at 09:27
  • 1
    Looky here: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html – idoby Jun 10 '13 at 09:35

2 Answers2

6

I'm expecting a link error because it'll conflict with the existing standard implementation.

Your expectation is incorrect: most UNIX libc implementations support using some other malloc. To that end, they put malloc, realloc, free etc. either into a separate object file, or each into an object file of its own.

The linker is then free to replace malloc.o in libc.a with your implementation. You can read about the algorithm the linker uses here. Once you understand the algorithm, it should be clear why linking your own malloc and free does not cause a link error.

UNIX shared libraries are explicitly designed to emulate archive libraries, so while details of why you don't get a link error when linking with libc.so are different, the spirit is the same.

However, you aren't done. Linking any moderately complicated program with your implementation will likely crash, because when you replace malloc, you also need to implement realloc, and likely calloc and memalign and posix_memalign. Otherwise, you'll get a mixture of implementations, and when someone passes realloced pointer to your free, things will likely explode.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
0

In my experience, it is standard practice for custom mallocs and frees to be named uniquely, such as the kernel malloc, kmalloc, and kernel free, kfree. If you're writing your own, I recommend giving a separate name for your functions.

How are you planning to allocate memory? Most of the time you should wrap around the malloc function to provide custom functionality, but still end up using malloc in some form or another. In my opinion, this is the route you should take, so I wouldn't be too hasty to dispose of the built in malloc and free functions unless you have good reason (or strong desire) to do so. Having them named the same will interfere with this.

This is the Minix implementation of malloc, just to give you a sense of what you're looking at.

coder543
  • 803
  • 6
  • 16