Why do you run objcopy after linking, and what do size/objdump/nm tell you?

After linking you have an ELF file, which contains the program plus metadata, section headers, symbol tables, debug info, that's great for a debugger but isn't what a flash programmer wants. objcopy -O binary (or -O ihex) strips the ELF down to the raw bytes that go into flash, producing the .bin/.hex the flashing tool writes to the device; you keep the ELF for debugging (GDB needs its symbols) and flash the stripped image. The inspection tools answer specific questions: size reports the byte sizes of .text, .data, and .bss, which tells you immediately whether the image fits the chip's flash and RAM, a daily sanity check. objdump -d disassembles the binary so you can see the actual instructions the compiler generated, invaluable for understanding optimization or chasing a hard fault to a specific instruction. nm lists the symbols (functions and globals) and their addresses, which helps track down "undefined reference" link errors or confirm a symbol landed where expected. readelf dumps the ELF structure (headers, sections, symbols) in detail. So objcopy is the format conversion to make a flashable image, and size/objdump/nm/readelf are the forensic tools for "does it fit, what did it compile to, where are the symbols."