Custom malloc/mmap for x86_64

[Mike Frysinger]

On Saturday 28 April 2012 19:47:19 Daniel wrote:
> Thank you guys for your quick replies. I have a separate library already
> working independently that supports my work. I was asked to migrate
>  it to glibc to provide an actual implementation and deploy it on a
> real system.
> 
> So to answer your questions: my_malloc and malloc, as well as
> my_mmap and mmap all have to be supported and may be called
> at any time. Whenever free() is called, it works perfectly since both
>  malloc and my_malloc operate over the same data structures,
> so I do not have to worry about keeping track of space that way.
> Moreover, malloc and my_malloc can grow the same
> heap/virtual address space for the given process.
> 
> So, basically, we just need to overload the above methods. I do not want
> to overwrite mmap nor malloc. I know how to do that via the -wrap flag
> as you guys mentioned. I also know about LD_PRELOAD variable.

if you want the whole system to use the wrappers and not just one or two apps, 
then you can use /etc/ld.so.preload.  every ELF that runs will first check that 
file and load any libs listed in it.

> But, back to my old question. Out of curiosity because I like to
>  know how things really work. How does glibc exaclty generate
>  wrappers for mmap, munmap, et al.?
> 
> I know the make-syscals.sh script creates syscall wrappers for
>  the methods specified in syscalls.list. But when I looked in there
>  I did not see mmap, munmap, sbrk, etc.

maybe you looked in the wrong syscalls.list file ?  these files stack, so you 
have to look at all the ones that come into play for your target.
$ find -name syscalls.list -exec grep mmap {} +
sysdeps/unix/sysv/linux/syscalls.list:
mmap	-	mmap	b:aniiii	__mmap	mmap
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-help/attachments/20120429/01a3b7cd/attachment.sig>