Was any form of compact unwind information considered for AArch64?

[smeenai]

The 32-bit ARM exception handling ABI defines the exidx and extab sections to encode unwinding information compactly. I don't have any implementation experience with these sections, but from a user perspective they seem to do their job very well. A few years ago, I measured that for the Facebook for Android app built for armv7, the combined size of the .ARM.exidx and .ARM.extab sections was 6.1% of total native library size. In contrast, for aarch64, the combined size of .eh_frame_hdr, .eh_frame, and .gcc_except_table was 14.7% of total native library size. I know that the comparison isn't entirely sensible, since the text segment size on armv7 is also much smaller (because of Thumb), but it gives a rough sense of how much larger regular DWARF unwinding information is.

Binary size is a pretty large concern for us, and we've often contemplated whether some form of compact unwind information encoding for AArch64 ELF would be worthwhile. (In addition to exidx/extab, Apple has their compact unwind format and Microsoft has their pdata/xdata format, so there's a lot of prior art to consider.) Is there any information that's publicly available (or could be publicly shared) about whether a compact unwind format was ever considered for AArch64 ELF? Were there any particular issues with exidx/extab that made them unsuitable to carry over to AArch64, or was it mostly a matter of prioritization and minimizing divergences from other platforms?

[rearnsha]

We did think about it at the time, but the focus for aarch64 was primarily on better compatibility with other 64-bit platforms, which all have an infrastructure based on dwarf encodings.
Another reason for not using a compact encoding route is that it can't directly support languages that have non-call exceptions (can catch exceptions from signals). This proved to be significant issue for aarch32 processors running linux.

[Wilco1]

Any format needs to handle shrinkwrapping and prolog scheduling where callee-saves are moved across the whole function, so that gives you non-call exceptions for free. One could certainly create a more compact variant but someone needs to put in the work to do a good design that shows significant gains (if it saves just 10-20%, it's not worth the effort).