I wonder if the toolchain generated unwind tables. It's not unusual to disable them in embedded contexts. Without them, the DWARF-based libgcc unwinder won't worm, obviously.
We didn't have a lot of available space, so all binaries deployed were stripped and we didn't ship any additional debug information. Hence why I left the DWARF parsing as an "exercise for the reader", I didn't do it back then. I had to use addr2line on my PC with the debug data I had locally.
The unwind tables are in an allocated section and cannot really be removed after the final link (it would change file offsets in places that had their relocations relaxed, without a trace). These unwind tables are separate from the debugging information.
Not after the final link, but I'm pretty sure we were using `-fdata-sections -ffunction-sections -Wl,--gc-sections`. I think that would strip any unwind section too, if it was present. Wouldn't it?
Anyway, we likely didn't generate them in the first place.
No, I think -Wl,--gc-sections still produces unwind data for the functions that remain. I suppose you could use the strip command on relocatable (intermediate) .o files. But the most common approach is probably building with -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables. Or perhaps the toolchain defaults to that when building C, which is an odd configuration for GNU/Linux because pthread_cancel actually uses unwinding in C (and -fexceptions avoids an unprotected function pointer on the stack that is called even on the non-canceling code path).
