Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Layout of a Program in C

web.eecs.utk.edu

Post reply on HN
Print view View original

1–10 of 38 posts

Re: Memory Layout of a Program in C

#2

Post by monocasa »

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

Re: Memory Layout of a Program in C

#3

Post by bra-ket »

monocasa wrote: post #2

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

is there a good reference you'd recommend?

Re: Memory Layout of a Program in C

#4

Post by megous »

monocasa wrote: post #2

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

    strace ls
    execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0
    brk(NULL)                               = 0x5581b6542000
I see brk(), that's glibc.

Re: Memory Layout of a Program in C

#5

Post by ChrisSD »

> As I have said previously, memory is like a huge array with (say) 0xffffffff elements. A pointer in C is an index to this array. Thus when a C pointer is 0xefffe034, it points to the 0xefffe035th element in the memory array (memory being indexed starting with zero).

I'm not sure how true this is outside of a particular platform/compiler. As far as I'm aware, C doesn't actually define how pointers are represented, only that they are a reference to memory (although null is a special case). Pointers in C are very abstract which allows for much more aggressive optimisations.

And all this is before we get into how memory actually works in practice, such as CPU cache lines.

Re: Memory Layout of a Program in C

#6

Post by monocasa »

megous wrote: post #4
monocasa wrote: post #2

So this is a whole lot more complicated these days. There's not one stack but many for the different threads, regions have guard pages typically, and all these regions are setup with mmap (so there's no sbrk syscall anymore) just for starters.

strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.

If you go into the kernel, it's implemented in terms of mmap/munmap.

Re: Memory Layout of a Program in C

#7

Post by pcwalton »

ChrisSD wrote: post #5

> As I have said previously, memory is like a huge array with (say) 0xffffffff elements. A pointer in C is an index to this array. Thus when a C pointer is 0xefffe034, it points to the 0xefffe035th element in the memory array (memory being indexed starting with zero). I'm not sure how true this is outside of a particular platform/compiler. As far as I'm aware, C doesn't actually define how pointers are represented, o…

You do have to be able to cast from a pointer to an appropriately-sized integer and back, however [1]. This makes the semantics fuzzy and ill-defined in some cases [2].

[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm#q3...

[2]: https://blog.regehr.org/archives/1621

Re: Memory Layout of a Program in C

#8

Post by chrisseaton »

ChrisSD wrote: post #5

> As I have said previously, memory is like a huge array with (say) 0xffffffff elements. A pointer in C is an index to this array. Thus when a C pointer is 0xefffe034, it points to the 0xefffe035th element in the memory array (memory being indexed starting with zero). I'm not sure how true this is outside of a particular platform/compiler. As far as I'm aware, C doesn't actually define how pointers are represented, o…

Yes you can implement C in other ways (I've worked on a C JIT that abstracts from this flat memory model, for example) but come on we all know this is how C works on most machines most of the time and they shouldn't need to add a lot of disclaimers that it could theoretically be done a different way when they're just trying to raise awareness of how things work in practice.

Re: Memory Layout of a Program in C

#9

Post by chrisseaton »

monocasa wrote: post #6
megous wrote: post #4

Earlier quoted context omitted.

strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.

If you go into the kernel, it's implemented in terms of mmap/munmap.

You said there was no sbrk syscall, and there is.

Re: Memory Layout of a Program in C

#10

Post by aidenn0 »

ChrisSD wrote: post #5

> As I have said previously, memory is like a huge array with (say) 0xffffffff elements. A pointer in C is an index to this array. Thus when a C pointer is 0xefffe034, it points to the 0xefffe035th element in the memory array (memory being indexed starting with zero). I'm not sure how true this is outside of a particular platform/compiler. As far as I'm aware, C doesn't actually define how pointers are represented, o…

Here's a real-word C compiler where the sizeof() everything is 1; https://github.com/vsedach/Vacietis

For another example, the LLVM webassembly backend doesn't put the call stack in the same address space as the heap at all.

Post reply on HN