Rust Before Main - Ryan Levick - Rust Linz, July 2022
Вставка
- Опубліковано 4 жов 2024
- 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.m...
How the heck do we get to main(): dbp-consulting....
Everything You Ever Wanted to Know About DLLs: • CppCon 2017: James McN...
Minimizing Rust Binary Size: github.com/joh...
Rust Linz: rust-linz.at
Speak at Rust Linz: sessionize.com...
Twitter: / rustlinz
It would be nice if the resource links at the end of the talk were in the youtube description too. But great talk btw!
Yeah, makes sense! I updated the description
Thanks❤
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!
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!
Incredible talk, would love to learn more in this direction, keep it coming Ryan!
5:30 in, and already very valuable! Thanks, Ryan!
One of the best, if not the best, I’ve watched on UA-cam so far. Thanks!
This was extraordinarily illuminating. Thank you! I’m grateful
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.
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.
Wow, such a nice intro. After half a minute I am really interested in the content of the talk.
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?
Fantastic very informative talk!
great presentation, thanks
Fantastic talk
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".
"My life is very much consumed by Rust" :)
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.
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?
I like that he basically gives therapy for people with impostor syndrome for the first few minutes.
This is a great resource, thanks a lot!
Excellent presentation and content!
Wonderful talk!!!!
great talk
Great talk, thanks!
very clear
Great talk. 🤩
I think it spells exec-ve (arg Vector and Env), not exe-cve
__start -> __lib_start_main -> main
But if we don't have a main in our Rust program anymore, how can this work?
Thanks 👍
Great presentation, thank you. Also very informative content.
Can you do some more talks?
I do not use Cargo too.
13:41 My whole life is a lie.
Who knows how to do this in MacOS M1?
You say “stood” for “std”?