|vid, 2007-09-24||Revision: 1.0|
Many assembly programmers make linux applications using only syscalls, without glibc. Altough this way is usually considered bad practice, it is a fact.
One problem that pops out when using only syscalls is lack of managed dynamic memory (heap). Linux kernel doesn't provide any heap management. For most applications, that functionality is provided by glibc.
First option is to use
sys_mmap() to allocate pages of memory.
This approach has several problems.
Most apparent problem is that smallest block that can be allocated
sys_mmap() has 4KB. That is too much for most cases when
allocation is needed.
Another problem is enlarging memory block. Dynamically allocated
blocks sometime need to be enlarged. When enlarging block,
often has to move block to different place. That means
all pointers to (and into) block has to be updated.
There is possibility to enlarge block without allowing system to move it, but that is very unrealiable way. It often fails and is practically unusuable.
Updating pointers may be sometimes hard, especially in assembly where using relative indexes to block wastes precious registers, and makes code a bit uglier.
These are two main reasons why
sys_mmap() may not be right solution.
There are also cases when
sys_mmap() works fine, then it is okay to
Another possibility is using
sys_brk(). This call is provided by
kernel specifically to allow writing heap manager using it.
This call allocates memory right behind application image in memory. Memory is never moved, so you will never need to update pointers. There is plenty of memory behind image, and enlarging this block is safe.
Problem could be that you only have one such block. If you need to allocate more blocks, you need some custom memory management. Still, for applications that need only simple management, like single list of fixed-size structures, this is fine solution.
For any more complex application, neither method is good enough, and some more complex heap management is needed.
Most common way is to use glibc. This is good and easy solution.
Some assembly programmers doesn't like using glibc. For them, there is assembly library FASMLIB, which provides heap manager too.
Unfortunately, these two libraries cannot be used together, because
they both use
sys_brk() to allocate memory pool.
Some people prefer writing their own heap manager.
Custom specialized memory managers usually perform better than general-purpose managers, which must provide all functionality needed. When memory management is bottleneck of application speed, one should consider writing memory manager specialized for actual task.
However, writing a good general-purpose heap manager is a very complicated task. Especially if it has to support multithreaded application (that usually isn't case in linux, but still...). If there is a heap manager alredy written, that does what you need, then my advice is to stick to existing one.
lscr, linux syscalls reference and headers
glibc, GNU implemenentation of C standard library, provides heap management
FASMLIB, general purpose assembly library, provides heap management
Continue to discussion board.
You can contact the author using e-mail firstname.lastname@example.org.
Visit author's home page.
|2007-09-24||1.0||First public version||vid|
(dates format correspond to ISO 8601)