Interested in knowing how libc works, or what happens in your program before main is called? This two-part tutorial takes you through all the magic under the covers (spoiler: it's just data structures all the way down).
G+: Interested in knowing how libc works, or what …
Reminds me of the time some guy tried to create the worlds smallest executable ELF binary:
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
45 bytes!
I also found it really fun from a historical point of view to mess around with DOS executables in an assembler. A .COM program is literally just code; it has no header. DOS just loads it into a fixed point in memory and jumps to it. So you can write a "Hello world" program that is not much longer than the 12 bytes of the string. And there is no libc, only BIOS calls. You compile it with NASM and run it with DOSBox.
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
45 bytes!
I also found it really fun from a historical point of view to mess around with DOS executables in an assembler. A .COM program is literally just code; it has no header. DOS just loads it into a fixed point in memory and jumps to it. So you can write a "Hello world" program that is not much longer than the 12 bytes of the string. And there is no libc, only BIOS calls. You compile it with NASM and run it with DOSBox.
Ah nice. That's also a really good article on the topic. Love how they start abusing the ELF spec there at the end.
If you wanted to ditch lib-c, you then have to do your own syscall handling. Calling "int 0x80" is pretty easy on x86, but I think it might not work on x86_64 (the preferred way seems to be calling vsyscall from the Kernel's VDSO and let it choose the right/fastest syscall mechanism).
The other bit I'm kind of interested in is what happens when you do SYS_execve - how much of it's handled by the kernel side and how much is done in userspace (probably need to dig around bionic or musl's source a bit more).
If you wanted to ditch lib-c, you then have to do your own syscall handling. Calling "int 0x80" is pretty easy on x86, but I think it might not work on x86_64 (the preferred way seems to be calling vsyscall from the Kernel's VDSO and let it choose the right/fastest syscall mechanism).
The other bit I'm kind of interested in is what happens when you do SYS_execve - how much of it's handled by the kernel side and how much is done in userspace (probably need to dig around bionic or musl's source a bit more).
"It's a wonder that Linux will even consent to sneeze on it, much less give it a process ID."