<- Back
Comments (25)
- mmastracAuthor here, happy to answer any questions. I've been working on building some higher-level abstractions on link sections (specifically, link-time optimized collections like maps (1) and sorted slices (2)) and wanted to share the hard-fought knowledge from the last couple of months.There's a decent amount of knowledge around pre-main work in Rust, but I think this is one of the first attempts to walk through mutable link sections, which open up a pretty wide world of optimization, IMO. Even without mutability, I figured there isn't nearly enough documentation on these approaches out there.(1) https://docs.rs/scattered-collect/0.20.0/scattered_collect/m...(2) https://docs.rs/scattered-collect/0.20.0/scattered_collect/s...
- jeffbeeThe general lesson of these things is main is not that special and it pays to understand how your program actually starts. This has little/nothing to do with Rust or other language tools. On Linux, given a static ELF program, the kernel returns to the IP given by e_entry, which can proceed to do anything. If the program is dynamic (has a .interp) then it loads the interpreter and returns to its e_entry instead. The interpreter, in turn, can do absolutely whatever.
- smy20011> This post is 100% human-written. Claude was used for feedback and to assist with the linker symbol diagram. Cursor was used for feedback and to ensure examples were compilable.Love this, I hope every blog have the same disclaimer about how AI is used.
- wild_pointerI thought it was about prehistoric Rust before the main branch was created :)
- ryanshrottI ran into this with embedded Rust: put alloc in a .init_array function, but the global allocator also uses .init_array, and there's no ordering guarantee. Took me hours to figure out why I was getting garbage from the heap before main.
- Suraceverything abount Rust MUST have some AI in it nowerdays. even this article