Added missing trusty patches (#8185)

cross/arm/trusty-lttng-2.4.patch

@@ -0,0 +1,71 @@
+From e72c9d7ead60e3317bd6d1fade995c07021c947b Mon Sep 17 00:00:00 2001
+From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Date: Thu, 7 May 2015 13:25:04 -0400
+Subject: [PATCH] Fix: building probe providers with C++ compiler
+
+Robert Daniels wrote:
+> > I'm attempting to use lttng userspace tracing with a C++ application
+> > on an ARM platform. I'm using GCC 4.8.4 on Linux 3.14 with the 2.6
+> > release of lttng. I've compiled lttng-modules, lttng-ust, and
+> > lttng-tools and have been able to get a simple test working with C
+> > code.  When I attempt to run the hello.cxx test on my target it will
+> > segfault.
+>
+>
+> I spent a little time digging into this issue and finally discovered the
+> cause of my segfault with ARM C++ tracepoints.
+>
+> There is a struct called 'lttng_event' in ust-events.h which contains an
+> empty union 'u'.  This was the cause of my issue.  Under C, this empty union
+> compiles to a zero byte member while under C++ it compiles to a one byte
+> member, and in my case was four-byte aligned which caused my C++ code to
+> have the 'cds_list_head node' offset incorrectly by four bytes.  This lead
+> to an incorrect linked list structure which caused my issue.
+>
+> Since this union is empty, I simply removed it from the struct and everything
+> worked correctly.
+>
+> I don't know the history or purpose behind this empty union so I'd like to
+> know if this is a safe fix.  If it is I can submit a patch with the union
+> removed.
+
+That's a very nice catch!
+
+We do not support building tracepoint probe provider with
+g++ yet, as stated in lttng-ust(3):
+
+"- Note for C++ support: although an application instrumented with
+   tracepoints can be compiled with g++, tracepoint probes should be
+   compiled with gcc (only tested with gcc so far)."
+
+However, if it works fine with this fix, then I'm tempted to take it,
+especially because removing the empty union does not appear to affect
+the layout of struct lttng_event as seen from liblttng-ust, which must
+be compiled with a C compiler,  and from probe providers compiled with
+a C compiler. So all we are changing is the layout of a probe provider
+compiled with a C++ compiler, which is anyway buggy at the moment,
+because it is not compatible with the layout expected by liblttng-ust
+compiled with a C compiler.
+
+Reported-by: Robert Daniels <robert.daniels@vantagecontrols.com>
+Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+---
+ include/lttng/ust-events.h | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/usr/include/lttng/ust-events.h b/usr/include/lttng/ust-events.h
+index 328a875..3d7a274 100644
+--- a/usr/include/lttng/ust-events.h
++++ b/usr/include/lttng/ust-events.h
+@@ -407,8 +407,6 @@ struct lttng_event {
+ 	void *_deprecated1;
+ 	struct lttng_ctx *ctx;
+ 	enum lttng_ust_instrumentation instrumentation;
+-	union {
+-	} u;
+ 	struct cds_list_head node;		/* Event list in session */
+ 	struct cds_list_head _deprecated2;
+ 	void *_deprecated3;
+-- 
+2.7.4
+

cross/arm/trusty.patch

@@ -0,0 +1,97 @@
+diff -u -r a/usr/include/urcu/uatomic/generic.h b/usr/include/urcu/uatomic/generic.h
+--- a/usr/include/urcu/uatomic/generic.h	2014-03-28 06:04:42.000000000 +0900
++++ b/usr/include/urcu/uatomic/generic.h	2017-02-13 10:35:21.189927116 +0900
+@@ -65,17 +65,17 @@
+ 	switch (len) {
+ #ifdef UATOMIC_HAS_ATOMIC_BYTE
+ 	case 1:
+-		return __sync_val_compare_and_swap_1(addr, old, _new);
++		return __sync_val_compare_and_swap_1((uint8_t *) addr, old, _new);
+ #endif
+ #ifdef UATOMIC_HAS_ATOMIC_SHORT
+ 	case 2:
+-		return __sync_val_compare_and_swap_2(addr, old, _new);
++		return __sync_val_compare_and_swap_2((uint16_t *) addr, old, _new);
+ #endif
+ 	case 4:
+-		return __sync_val_compare_and_swap_4(addr, old, _new);
++		return __sync_val_compare_and_swap_4((uint32_t *) addr, old, _new);
+ #if (CAA_BITS_PER_LONG == 64)
+ 	case 8:
+-		return __sync_val_compare_and_swap_8(addr, old, _new);
++		return __sync_val_compare_and_swap_8((uint64_t *) addr, old, _new);
+ #endif
+ 	}
+ 	_uatomic_link_error();
+@@ -100,20 +100,20 @@
+ 	switch (len) {
+ #ifdef UATOMIC_HAS_ATOMIC_BYTE
+ 	case 1:
+-		__sync_and_and_fetch_1(addr, val);
++		__sync_and_and_fetch_1((uint8_t *) addr, val);
+ 		return;
+ #endif
+ #ifdef UATOMIC_HAS_ATOMIC_SHORT
+ 	case 2:
+-		__sync_and_and_fetch_2(addr, val);
++		__sync_and_and_fetch_2((uint16_t *) addr, val);
+ 		return;
+ #endif
+ 	case 4:
+-		__sync_and_and_fetch_4(addr, val);
++		__sync_and_and_fetch_4((uint32_t *) addr, val);
+ 		return;
+ #if (CAA_BITS_PER_LONG == 64)
+ 	case 8:
+-		__sync_and_and_fetch_8(addr, val);
++		__sync_and_and_fetch_8((uint64_t *) addr, val);
+ 		return;
+ #endif
+ 	}
+@@ -139,20 +139,20 @@
+ 	switch (len) {
+ #ifdef UATOMIC_HAS_ATOMIC_BYTE
+ 	case 1:
+-		__sync_or_and_fetch_1(addr, val);
++		__sync_or_and_fetch_1((uint8_t *) addr, val);
+ 		return;
+ #endif
+ #ifdef UATOMIC_HAS_ATOMIC_SHORT
+ 	case 2:
+-		__sync_or_and_fetch_2(addr, val);
++		__sync_or_and_fetch_2((uint16_t *) addr, val);
+ 		return;
+ #endif
+ 	case 4:
+-		__sync_or_and_fetch_4(addr, val);
++		__sync_or_and_fetch_4((uint32_t *) addr, val);
+ 		return;
+ #if (CAA_BITS_PER_LONG == 64)
+ 	case 8:
+-		__sync_or_and_fetch_8(addr, val);
++		__sync_or_and_fetch_8((uint64_t *) addr, val);
+ 		return;
+ #endif
+ 	}
+@@ -180,17 +180,17 @@
+ 	switch (len) {
+ #ifdef UATOMIC_HAS_ATOMIC_BYTE
+ 	case 1:
+-		return __sync_add_and_fetch_1(addr, val);
++		return __sync_add_and_fetch_1((uint8_t *) addr, val);
+ #endif
+ #ifdef UATOMIC_HAS_ATOMIC_SHORT
+ 	case 2:
+-		return __sync_add_and_fetch_2(addr, val);
++		return __sync_add_and_fetch_2((uint16_t *) addr, val);
+ #endif
+ 	case 4:
+-		return __sync_add_and_fetch_4(addr, val);
++		return __sync_add_and_fetch_4((uint32_t *) addr, val);
+ #if (CAA_BITS_PER_LONG == 64)
+ 	case 8:
+-		return __sync_add_and_fetch_8(addr, val);
++		return __sync_add_and_fetch_8((uint64_t *) addr, val);
+ #endif
+ 	}
+ 	_uatomic_link_error();