11–20 of 38 posts
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.
Earlier quoted context omitted.
strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.
brk() is undefined behavior if mmap is ever called.
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.
> 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.
> 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…
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.
Earlier quoted context omitted.
strace ls execve("/usr/bin/ls", ["ls"], 0x7ffd86646d90 /* 61 vars */) = 0 brk(NULL) = 0x5581b6542000 I see brk(), that's glibc.
brk() is undefined behavior if mmap is ever called.
> 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…
Indeed and it was really fun to work with pointers for programs targeting 16 bit (real mode) MS DOS.
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.
https://stackoverflow.com/questions/30542428/does-malloc-use...
there is a mallopt named M_MMAP_THRESHOLD, in general:
If requested memory is less than it, brk() will be used;
If requested memory is larger than or equals to it, mmap() will be used;