This patch simplifies the isRelRelative for AArch64 to just handle the
cases where it is not relative, instead of list all the relocations
that is. It also adds more testing for shared objects creation.
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
bool AArch64TargetInfo::isRelRelative(uint32_t Type) const {
- return Type == R_AARCH64_PREL32 || Type == R_AARCH64_ADR_PREL_PG_HI21 ||
- Type == R_AARCH64_LDST8_ABS_LO12_NC ||
- Type == R_AARCH64_LDST32_ABS_LO12_NC ||
- Type == R_AARCH64_LDST64_ABS_LO12_NC ||
- Type == R_AARCH64_ADD_ABS_LO12_NC || Type == R_AARCH64_CALL26;
+ switch (Type) {
+ default:
+ return true;
+ case R_AARCH64_ABS64:
+ case R_AARCH64_ADR_GOT_PAGE:
+ case R_AARCH64_LD64_GOT_LO12_NC:
+ return !Config->Shared;
I don't think this makes sense. The relocations have different
definitions depending on -shared? If not, how come they become
relative or not depending on -shared?
Cheers,
Rafael
Comment Actions
They do have different semantics depending if the code is position independent (which it is not only shared, but also PIE executables) and this method is used to define whether we will emit or not a dynamic relocation. If you check, gold is doing pretty much this in its local scan.