This is an archive of the discontinued LLVM Phabricator instance.

[XRay] Change ARM/AArch64/powerpc64le to use version 2 sled (PC-relative address)
ClosedPublic

Authored by MaskRay on Apr 21 2020, 2:07 PM.

Details

Summary

Follow-up of D78082 (x86-64).

This change avoids dynamic relocations in xray_instr_map for ARM/AArch64/powerpc64le.

MIPS64 cannot use 64-bit PC-relative addresses because R_MIPS_PC64 is not defined.
Because MIPS32 shares the same code, for simplicity, we don't use PC-relative addresses for MIPS32 as well.

Tested on AArch64 Linux and ppc64le Linux.

Diff Detail

Event Timeline

MaskRay created this revision.Apr 21 2020, 2:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 21 2020, 2:07 PM
Herald added subscribers: Restricted Project, danielkiss, steven.zhang and 8 others. · View Herald Transcript

@dberris xray_fn_idx is still using absolute relocations and thus must have the SHF_WRITE flag. If we are also going to make it read-only, how can we address compatibility issues in compiler-rt/lib/xray ?

MaskRay updated this revision to Diff 259106.Apr 21 2020, 2:21 PM

Fix ARM (I can't test, though)

@MaskRay for what it's worth i'm currently trying to make xray_fn_idx optional - we tend to patch an entire DSO at a time so we don't need it to find individual sleds (I think we could support the entire compiler-rt interface, just slower, without it). Perhaps if someone cares about avoiding the relocations in xray_fn_idx they could just use the option to omit it as well.

@dberris xray_fn_idx is still using absolute relocations and thus must have the SHF_WRITE flag. If we are also going to make it read-only, how can we address compatibility issues in compiler-rt/lib/xray ?

Okay, that one's a little tougher, because the index entries don't have a version. :(

We have options:

  1. Leave this as-is.
  2. Check at runtime whether the index start is a relative address (i.e. whether the higher order bits in x86 are non-zero) or if index start is zeros because the relative offsets (32-bits) are packed into the index end quad, and handle accordingly. It might introduce an overhead (probably not measurable either). Warn once if we ever encounter the absolute addresses (can be done in xray_init.cpp).
  3. Do an ABI break and expand the index entries to include index versions.

If we can do 2 in a portable manner, that would be nice to start with.

If we need to go to 3, then we might consider a transition plan:

  • First, create a different index for the read-only section, in parallel (flag-controlled). This would make it possible to check at runtime whether you have two different index sections and warn. Use the read-write version first, but flag-control the runtime to attempt to use the read-only section.
  • When enough time has passed (maybe one release) we can make the runtime default to using the read-only section.
  • Update the compiler to not emit the read-write section anymore, and remove the code in the runtime referring to the read-write section.

I understand that 3 is cumbersome but it's probably the safest way to transition off the read-write sections.

Does this patch itself look good?

ianlevesque accepted this revision.Apr 23 2020, 9:45 PM
This revision is now accepted and ready to land.Apr 23 2020, 9:45 PM

Thank you for doing this @MaskRay!

This revision was automatically updated to reflect the committed changes.

@ianlevesque if you just accept without a message, a mail doesn't get sent to the appropriate *-commits list, which can be confusing for people browsing that list. It's a good idea to always accept with a "LGTM" or similar message to fix that.