Tuesday, December 1. 2009
malloc() does not necessarily unmap free'd pages
malloc uses a combination of brk() and mmap() (where available) system calls depending upon the size of the chunk being allocated and some other factors like holes in the address space. a brk() only increases the data segment of a process in turn increasing the address space of that process. When you free() it, libc only marks this chunk as un-available but it still remains mapped. If malloc() uses mmap(), a free would so a munmap() and then later on accessing a freed memory will result in a seg-fault.
There's a comment in glibc's mmap.c that says:
Define HAVE_MMAP as true to optionally make malloc() use mmap() to
allocate very large blocks. These will be returned to the
operating system immediately after a free(). Also, if mmap
is available, it is used as a backup strategy in cases where
MORECORE fails to provide space from system.
This malloc is best tuned to work with mmap for large requests.
If you do not have mmap, operations involving very large chunks (1MB
or so) may be slower than you'd like.
The default mmap() threshold is 128*1024 bytes (or 128 KB). This value can be changed using mallopt() glibc call:
http://www.gnu.org/s/libc/manual/html_node/Malloc-Tunable-Parameters.html
signal handlers are executed in the context of their own private stack frame
see arch specific setup_frame() function in the kernel. For mips, it installs the signal trampoline, the user context (the registers) and the siginfo (when appropriate). The trampoline is just a syscall trap to the kernel to call sigreturn(). The address of the trampoline is set in the RA register, the arguments (signr, siginfo and the signal context) in registers 4, 5 and 6 respectively, pc points to the sighandler, reg# 29 (stack ptr) points to the allocated stack frame and off you go! On completion of the handler, the user land code returns to the address pointed to by RA register which has the trampoline. This it traps to the kernel in sysexit() syscall and this syscall then restores the user context through the saved register set, saved earlier in reg# 6.
Dump gcc built-in #defs
This is very useful if you have say two different compilers compiling the same piece of code and you want to execute some special code only for one of the compilers. Do this:
#> gcc -E -dD -
ctrl-D
This will dump all the inbuilt #defs. For example, if gcc was cross compiled for mips target, you'd have something like this somewhere in that dump:
...
# 1 ""
#define _mips_ 1
# 1 ""
#define _mips 1
# 1 ""
#define mips 1
# 1 ""
#define __mips64 1
# 1 ""
...
and if your compiler was compiled with target intel, you'd see this:
...
# 1 ""
#define __i386 1
# 1 ""
#define _i386_ 1
# 1 ""
#define i386 1
# 1 ""
...
So in your code, you can do this:
# ifdef _mips_
/ mips specific code /
#endif
etc.
Cool eh?
Find the offsets of data structures easily
From Kaz's post in LKML:
http://lkml.org/lkml/2009/11/20/449
Thursday, July 30. 2009
#> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Git repository quick howto:
http://landley.net/writing/git-quick.html
http://linux.yyz.us/git-howto.html
Tuesday, November 27. 2007
Hey Everyone,
I am finally working after completing my M.Sc. My company Zeugma Systems (http://www.zeugmasystems.com) is located at Richmond. Here I am working in the kernel development team. Pretty exciting eh?
|