[PATCH] D59216: [LLD][ELF][ARM] Redesign of .ARM.exidx handling to use a SyntheticSection

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 26 03:05:24 PDT 2019


peter.smith added a comment.

In D59216#1441965 <https://reviews.llvm.org/D59216#1441965>, @ruiu wrote:

> This may be a silly question, but is --emit-reloc for .ARM.exidx important? If we re-create an .ARM.exidx section, we probably have to re-create a relocation section for .ARM.exidx just for --emit-relocs, but I'm wondering if there's an actual user who wants that behavior. Perhaps this is a kind of question no one really knows, though...


I think it is a good question. I've only come across two use cases for it, the first is as a form of dynamic linking for OS kernels that want to avoid GOT style PIE/PIC. Examples include x86 and mips linux kernel, and I've also seen it in Fuchsia, which may use Arm. However in the case of an OS kernel I'm not expecting any C++ exceptions. The second use case is binary analysis where some tool such as Facebook's Bolt post-processes the ELF file guided by the relocations, in this particular case I'm guessing that relocations in C++ exception tables aren't that interesting, it would certainly be possible to derive the relocations from the table output.

Given that the relocations for --emit-relocs had been broken when table merging is on for some time (retained relocations for dropped sections) I suspect that no-one cares about it right now. For now I'd be happy to remove all relocation sections from the Input .ARM.exidx sections when --emit-relocs were used. If someone came up with a critical use case then we could add them back. Does that sound like a way forward?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59216/new/

https://reviews.llvm.org/D59216





More information about the llvm-commits mailing list