+ true if the symbol may be affected by dynamic relocations.
+
+ TARGET_ID_SHARED_LIBRARY and TARGET_SEP_DATA are designed to support
+ a read-only text segment without imposing a fixed gap between the
+ text and data segments. As a result, the text segment cannot refer
+ to anything in the data segment, even in PC-relative form. Because
+ .eh_frame refers to both code and data, it follows that .eh_frame
+ must be in the data segment itself, and that the offset between
+ .eh_frame and code will not be a link-time constant.
+
+ In theory, we could create a read-only .eh_frame by using DW_EH_PE_pcrel
+ | DW_EH_PE_indirect for all code references. However, gcc currently
+ handles indirect references using a per-TU constant pool. This means
+ that if a function and its eh_frame are removed by the linker, the
+ eh_frame's indirect references to the removed function will not be
+ removed, leading to an unresolved symbol error.
+
+ It isn't clear that any -msep-data or -mid-shared-library target
+ would benefit from a read-only .eh_frame anyway. In particular,
+ no known target that supports these options has a feature like
+ PT_GNU_RELRO. Without any such feature to motivate them, indirect
+ references would be unnecessary bloat, so we simply use an absolute
+ pointer for code and global references. We still use pc-relative
+ references to data, as this avoids a relocation. */