Reached mainline in https://reviews.llvm.org/rL305072 . (with Dean's comment implemented)

@dberris , I've reviewed it, but I'm not sufficiently qualified for this as I am not familiar with some parts of LLVM touched...
To the extent of my knowledge, this looks good.

Reached mainline in revision 293505.

@rengolin , I think your link to the mailing list is wrong. Here is the correct one: https://groups.google.com/forum/#!topic/llvm-dev/2Lt6DEZLgmo

Reached mainline in revision 293186.

Reached mainline in revision 293185.

Reached mainline in revision 293082.

Reached mainline in revision 293080.

Added checking for xray instrumentation map emission in the test.

As I understood, this patch starts adding a possibility to pass custom events to the XRay logging mechanism. So isn't it more logical to call it "custom event" rather than "custom log"? Another reason, I saw some terms similar to "custom log" somewhere in @dberris 's commits, perhaps in FDR. So I think it's desirable to avoid confusion.
And a general question: how are you going to pass these custom events to XRay logging, if currently the handler callback is not designed to take a pointer argument? It currently takes the function id and call reason code as arguments. Are you going to add the 3rd parameter like void* Data to the handler function? Trampolines may need adjustment in that case on some platforms.

Ping?

Ping?

With Thumb fix, in mainline at 292517.

Again in mainline at revision 292516.

Just submitting the same changes trying to workaround a glitch in Arcanist...

Please, note that this change can stay in mainline if https://reviews.llvm.org/D28623 is reverted because that one is real build-breaker.

Added detection of -mthumb test compiler option, so to mark tests as unsupported on Thumb because XRay doesn't yet support Thumb CPU mode on Arm32.

Reached mainline in 292211. Thanks all!

PTAL.

I don't see anything wrong with it so far.

In D28673#645485, @rengolin wrote:

Where is this used?

In D28623#645392, @rengolin wrote:

Almost. After applying both patches, I still get:

TestCases/Linux/patching-unpatching.cc

patching-unpatching.cc:30:17: error: expected string not found in input
 // CHECK-NEXT: called: {{.*}}, type=0
                ^
<stdin>:3:1: note: scanning from here
always instrumented called
^
<stdin>:3:21: note: possible intended match here
always instrumented called
                    ^

@rengolin , did you first apply patch https://reviews.llvm.org/D28624 before testing the current patch?
Especially the last quoted failed test seems to behave as if emission of XRay table is still broken.

Removed the patch piece which enables back testing of XRay on Arm32 , because it goes in a separate patch ( https://reviews.llvm.org/D28623 )

Removed the changes fixing Arm32 XRay (as they are in a separate patch https://reviews.llvm.org/D28624 ).

@rengolin , yes, please. This patch should be tested together with https://reviews.llvm.org/D28624 , because this patch only enables the tests and that one repairs XRay on Arm32.

Reached mainline in revision 291568.

In D27996#641145, @rovka wrote:

Hi,

Looks like this slipped through the cracks, I'll do a native run for you today and let you know how it goes.

Thanks.

Ping?

At a minimum, during x86_64-Linux to AArch64-Linux cross-compilation it didn't compile because of extern "C" missing. And the compiled program runs well on QEmu-AArch64-Linux .
@rengolin , what do you mean by "testing native" ? If that's compiling LLVM on AArch64 machine (i.e. without cross-compilation), then it would be challenging for me to do because on QEmu a LLVM build takes about a week, and the OS in the Arm32/AArch64 machines our team has is not exactly Linux.

I have been able to reproduce the problem when cross-compiling from x86_64-Linux to AArch64-Linux. Investigating now...

The second iteration has reached mainline in revision 290452 .

Added the forward declaration for ____clear_cache() to fix the build.

As discussed here , presence or absence of __clear_cache built-in depends on the compiler options. The built-in is common to gcc and clang, just currently in clang it is implemented via a called function in compiler-rt, but (another version of) gcc may inline it as an intrinsic. As discussed here , earlier there was a bug in gcc that gcc was expecting the parameters to be void*, in contradiction to the documentation which says they are char*, and clang developers implemented this bug too (so that parameters are void*), and I understood that clang developers were then fixing this bug.

In D27996#629921, @rengolin wrote:

This broke the build. Did you manage to build this on AArch64? How did you test this?

Reached mainline in https://reviews.llvm.org/rL290354 .

In D27038#619598, @dberris wrote:

Ping? @rSerge