Two main additions. First, a custom linker script (.ld): a desktop relies on the OS and a default script to place sections, but on bare metal you must tell the linker the chip's memory map, .text/.rodata into flash at its base address, .data/.bss into RAM, and define the initial stack pointer and vector table location. Second, an objcopy step that converts the linked ELF into a raw .bin or Intel .hex: the ELF carries debug info and section headers useful to a debugger, but the flashing tool just wants the literal bytes to write to flash. You also typically link startup code that copies .data from flash to RAM and zeroes .bss before main, since there's no OS loader to do it.
C Programming · Interview question
On an embedded target, what extra build steps exist beyond a desktop compile, and why?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
The C Compilation Pipeline
What gcc actually does between your .c file and a flashable binary, and why 'undefined reference' and 'implicit declaration' are different bugs at different stages.