HackerTrans
TopNewTrendsCommentsPastAskShowJobs

mierle

no profile record

comments

mierle
·3 jaar geleden·discuss
I work on Pigweed, a suite of embedded C++ tools and libraries. A major focus for us is size optimization, and we've written up some of our learnings:

https://pigweed.dev/docs/size_optimizations.html
mierle
·4 jaar geleden·discuss
Wow, it's cool to see astrometry.net get put to use! I worked on astrometry.net back in undergrad and grad school. If you have questions about how it works, I can answer them.

How does it work? astrometry.net uses 4-star combinations to define codes, then indexes the codes on the celestial sphere. The particulars of each of these phases matter, but that's the basic idea.
mierle
·4 jaar geleden·discuss
Take a look at Veritasium's perspective on this issue [1]. Veritasium reflects on clickbait thumbnails from the content producer perspective, and balances that against the motivation behind YouTube's algorithms. His final conclusion is that cilckbait isn't all bad, and that it serves an important purpose for both viewers and content creators. His classification of clickbait into different types is also fascinating.

[1] https://www.youtube.com/watch?v=S2xHZPH5Sng
mierle
·4 jaar geleden·discuss
The key to understanding ELF is that it serves three purposes:

(1) Execution - A container describing how an OS can load and execute a binary

(2) Linking - A container with relocatable machine code; for the linker to assemble

(3) Metadata for debugging and other purposes like stack traces

Program headers describe "segments". Segments are for the execution time view of the ELF. They describe the parts of the file to load into memory regions, and the execution entry address. The program headers are what are read by the OS when running "./my_executable". The segments don't always have names. Also, it is confusing that "sections" and "segments" mean very different things, but that's just how it is.

Thus, program headers (and the segments they describe) are for #1 - Execution.

Sections are a link-time construct, leveraged by the linker, to decide how to allocate functions and data to the execution segments (via sections). Intermediate ELF object files contain relocatable code, where the code is allocated to sections (you can manually specify them if you want). Example sections include ".text", which is executable code; ".bss" which is zero-initialized static variables; ".data" which is pre-initialized static variables, and so on. You can see an example of sections being allocated to segments in this thoroughly described linker script [1]. Sections are mostly ignored during program execution.

Thus, section headers (and the sections they describe) are for #2 - Linking.

You aren't alone in not knowing these details about ELF. It wasn't until I got into the embedded space that I dug deep to understand linking and loading, linker scripts, and executable formats. These details are important to understand for microcontrollers since you may need to carefully allocate code to physical addresses that have faster memory (e.g. core coupled RAM), or put code in flash. In some cases you execute code directly out of flash (so must tell the linker that including physical addresses); but in other cases, you might need to load code into RAM (manually, there is no OS!) from flash since executing out of flash can be slow. On desktops and servers, it's rare to change (or even know about) linker scripts.

[1] https://blog.thea.codes/the-most-thoroughly-commented-linker...