Discard the unused .eh_frame unwind tables - #652
Conversation
A unikernel never unwinds through DWARF, but .eh_frame and .eh_frame_hdr are SHF_ALLOC and sit in a PT_LOAD segment, so they are mapped into every image and strip cannot reclaim them. Moving them to /DISCARD/ removes about 0.5 MiB from every unikernel (a hello-world image shrinks ~45%).
It is, in fact, necessary. Solo5 is not exclusive to OCaml. |
|
Does the solo5-hvt-debug with the gdb interaction use eh_frame? I'm not sure whether this is part of the test suite.
Is there another path to solve this? Can there be arguments passed to "strip" to allow discarding these? Can it be marked differently? Would a custom strip (how hard can it be?) be sensible? Are there different strip utilities with the same behaviour, or are they all the same? |
3 participants
Every unikernel image maps
.eh_frameand.eh_frame_hdr, but nothing in a Solo5 guest unwinds through them: the tenders don't, and the runtimes that target Solo5 (OCaml/MirageOS, freestanding C) either use their own unwinding or none at all. Because the sections areSHF_ALLOCthey land in aPT_LOADsegment, so they are loaded into every image andstripcannot reclaim them.This moves
.eh_frame/.eh_frame_hdrto/DISCARD/in all six bindings' linker scripts, the same way the scripts already discard the GNU NOTEs. It removes about 0.5 MiB from every image: a hello-world unikernel drops from 1,2M to 600k, and larger images shrink by the same absolute amount.A guest that genuinely relies on DWARF unwinding (C++ exceptions, Rust
panic=unwind) would need these tables. If that is a use case worth keeping, I am happy to gate the discard behind an option instead.