HXBC.us - 竹難月金

Title:
Body:

> Been experimenting with writing a garbage collector lately. One of the problems I faced was how to walk the stack/heap/data section for all the (potential) pointers. The solution that I come up with probably only works for 32bit x86 Linux, and even then maybe making some bad assumption about memory alignment, among other things. Still, this maybe useful for other curious minds out there.
> 
> First there are `etext`, `edata` and `end`. Those 3 symbols are not normally defined, so you can define variables with those names if you want. But if you do:
> 
>     extern unsigned int etext, edata, end;
> 
> `ld` (or maybe something else, I can't find where I originally read this) will define those symbols if they don't resolve to anything else. Their values are meaningless, only their addresses are useful. `&etext` is the starting address for the text section, `&edata` is the end of text section and also the beginning of data section. `&end` is the end of data section and also the beginning of the heap. The type that you declare `etext` et al with is probably unimportant.
> 
> For memory allocators that use `sbrk()`, you can also use `sbrk(0)` to find the end of the heap. I've read that glibc uses mmap for `malloc()`s that are over certain sizes, so that may break things if you mix `sbrk(0)` and `malloc()`.
> 
> The stack is a little bit trickier, everywhere I've looked suggests that there is no portable way to walk the stack. Here's the code snippet that I am using:
> 
>     register gulong *fp __asm ("%ebp");
>     
>     /* skip the current frame because I don't want to walk the current
>        function */
>     gulong *ptr = (gulong *)*fp;
>     do {
>         gulong *saved = ptr + 4;
>         ptr = (gulong *)*ptr;
>         
>         if (ptr == NULL) {
>             break;
>         }
>         
>         // do something from "saved" to "ptr"
>     } while (1);
> 
> As you can see, I first define a variable for `%ebp`, which is the x86 way of saying `$fp`. `0(%ebp)` contains the address of the previous frame pointer, the last of which points to `NULL`. Incrementing by 4 maybe a bad assumption though, there maybe cases where 2 is more appropriate.