This is an archive of the discontinued LLVM Phabricator instance.

[XRay][compiler-rt] Add function id utilities for XRay
ClosedPublic

Authored by dberris on May 3 2017, 11:49 PM.

Details

Summary

This change allows us to provide users and implementers of XRay handlers
a means of converting XRay function id's to addresses. This, in
combination with the facilities provided in D32695, allows users to find
out:

  • How many function id's there are defined in the current binary.
  • Get the address of the function associated with this function id.
  • Patch only specific functions according to their requirements.

While we don't directly provide symbolization support in XRay, having
the function's address lets users determine this information easily
either during runtime, or offline with tools like 'addr2line'.

Diff Detail

Repository
rL LLVM

Event Timeline

dberris created this revision.May 3 2017, 11:49 PM
dblaikie accepted this revision.May 4 2017, 10:30 AM

Slightly curious to me that function IDs are > 0, but use a signed type - but no big deal, I guess there's probably a reason.

test/xray/TestCases/Linux/func-id-utils.cc
26–28 ↗(On Diff #97780)

What does this test?

Should the test case print the &foo and &bar, or assert(xray_function_address(1) == &foo), etc?

This revision is now accepted and ready to land.May 4 2017, 10:30 AM
dberris marked an inline comment as done.May 4 2017, 4:53 PM

Slightly curious to me that function IDs are > 0, but use a signed type - but no big deal, I guess there's probably a reason.

I agonised over this for a while. There's no real reason why it's signed, but changing it now might be too late (unless we start doing XRay versioning of the sleds). It's hard to assume that when we're laying down bytes in the binary with the compiler that signed numbers and unsigned numbers have the same representation (maybe they are for one platform, while not in another).

I suspect we can change it. Probably should do it a later time though. :)

test/xray/TestCases/Linux/func-id-utils.cc
26–28 ↗(On Diff #97780)

It does look a little goofy, but it's testing that:

  • We do have functions instrumented (i.e. __xray_max_function_id() != 0).
  • The maximum function id has an address associated with it.
  • We don't have a function id 0 that has an address. :)

While it's tempting to print the addresses of function id's and check, unfortunately we cannot assume that the compiler/linker will lay out the functions in a stable manner -- and thus function id's won't be guaranteed to always be mapped to specific function name.

dberris updated this revision to Diff 97898.May 4 2017, 5:34 PM
dberris marked an inline comment as done.

Update tests to actually check the addresses.

This revision was automatically updated to reflect the committed changes.