[PATCH] D32846: [XRay][compiler-rt] Add function id utilities for XRay

Dean Michael Berris via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 4 16:53:35 PDT 2017


dberris marked an inline comment as done.
dberris added a comment.

In https://reviews.llvm.org/D32846#746274, @dblaikie wrote:

> 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. :)



================
Comment at: test/xray/TestCases/Linux/func-id-utils.cc:26-28
+  // CHECK-LABEL: addresses:
+  // CHECK: #[[MAX]] -> @[[ADDR:.*]]
+  // CHECK-NOT: #0 -> @{{.*}}
----------------
dblaikie wrote:
> What does this test?
> 
> Should the test case print the &foo and &bar, or assert(xray_function_address(1) == &foo), etc?
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.


https://reviews.llvm.org/D32846





More information about the llvm-commits mailing list