Rust Before Main - Ryan Levick - Rust Linz, July 2022

When you run a Rust program, you may be tempted to think that the first code to execute is the main function. However, this is far from the case. In this talk, we'll explore what happens before the main function runs. By the end, you'll have a deeper understanding of what happens before the bits that rustc compiles your program into ever run.
Ryan has been writing Rust since around version 0.10. He now focuses on Rust full time at Microsoft. When he's not doing Rust, he enjoys cooking, traveling and exploring Berlin where he lives.
Resources:
The Bits Between the Bits: • CppCon 2018: Matt Godb...
Making Your Own Executable Packer: fasterthanli.me/series/making...
How the heck do we get to main(): dbp-consulting.com/tutorials/d...
Everything You Ever Wanted to Know About DLLs: • CppCon 2017: James McN...
Minimizing Rust Binary Size: github.com/johnthagen/min-siz...
Rust Linz: rust-linz.at
Speak at Rust Linz: sessionize.com/rust-linz
Twitter: / rustlinz

[@leonie9248]

Wow, this was amazingly informative! Thank you so much, Ryan!
Especially awesome: You always help to orient after each section, and at the end of the talk. This helps tremendously to put the pieces together in one's head!

[@cloudsquall88]

Really really amazing talk! One of the rare ones where you get taught things you didn't even know you wanted to learn. Ryan is a treasure, for real. Many thanks!

[@rauno56]

5:30 in, and already very valuable! Thanks, Ryan!

[@Ma1ne2]

Incredible talk, would love to learn more in this direction, keep it coming Ryan!

[@XiaoZhang-x1a0]

One of the best, if not the best, I’ve watched on RUclips so far. Thanks!

[@cthutu]

It would be nice if the resource links at the end of the talk were in the youtube description too. But great talk btw!

[@RustVideos]

Yeah, makes sense! I updated the description

[@muezsier]

Thanks❤

[@Shan224]

This was extraordinarily illuminating. Thank you! I’m grateful

[@alter_igel]

This is a great resource, thanks a lot!

[@JoeBurnett]

Excellent presentation and content!

[@5V500mA]

Wow, such a nice intro. After half a minute I am really interested in the content of the talk.

[@firex5250]

Wonderful talk!!!!

[@joelmontesdeoca6572]

Fantastic talk

[@SVVV97]

Great talk, thanks!

[@CjqNslXUcM]

I like that he basically gives therapy for people with impostor syndrome for the first few minutes.

[@GSteel-rh9iu]

Fantastic very informative talk!

[@AhmedEssam_eramax]

great presentation, thanks

[@StonkeyKong]

Great talk. 🤩

[@emvdl]

Thanks 👍

[@blenderpanzi]

Small note: "All the shell does is to call exec*()." It calls fork() before it, because exec*() _replaces_ the currently running process with the new binary. And between fork() and exec*() the shell might set up stdio redirection and such.
Linux does not have a system call that does both in one, which can be a problem for huge processes, because while the cloned memory is copy on write, the page-tables need to be copied, and if those alone are huge it is still a heavy operation. They say its a problem for PostgreSQL and why you should limit connections to your PostgreSQL server? There is the posix_spawn() function, but under Linux it just does fork()+exec*(). Some BSDs actually implement posix_spawn() as system call. I think Windows only has something like that and no way to exec*() without spawning a new process.

[@GK-rl5du]

This is really cool. Where can I learn about what a shell does before calling fork + exec* apart from stdio redirectioons. I heard some shells handle signals as well.

[@user-ju1qd9ek2m]

very clear

[@lectromoe]

great talk

[@elgalas]

"My life is very much consumed by Rust" :)

[@edgeeffect]

As an assembly language geek and a fan of `#![no_std]` ... this was always a favourite topic of mine even before Rust came along.
I love that "Not necessarily wrong... just a bit too simple".

[@simonfarre4907]

The vdso basically is a couple of system calls that are loaded into the process space so that the application can call those without having to actually make the system call "dance" as it were, no going into kernel space for it. For instance, I think gettimeofday or something like that, lives there. Why is this important? Its because system calls are a lot more costly than normal user space function calls. So, pulling these small syscalls into the process space, removes the need for context switching back and forth between user space and kernel space, making those calls almost equivalent to a normal function call.

[@GK-rl5du]

Interesting. So, these syscalls are executed without the need for ring0. May I ask what are these syscalls and how does kernel know before hand the arguments for these syscalls?

[@barower]

9:06 why does cargo/rustc have to statically embed entirety of standard library into final binary, and not only used elements, since it should know which of those are actually used?

[@ozanmuyes]

Great presentation, thank you. Also very informative content.

[@docteurklein]

I think it spells exec-ve (arg Vector and Env), not exe-cve

[@kamertonaudiophileplayer847]

I do not use Cargo too.

[@bobby9568]

Can you do some more talks?

[@thingsiplay]

__start -> __lib_start_main -> main
But if we don't have a main in our Rust program anymore, how can this work?

[@musdevfrog]

13:41 My whole life is a lie.

[@rasheedstarlet]

Who knows how to do this in MacOS M1?

[@FaZekiller-qe3uf]

You say “stood” for “std”?