Hi David,

  Please could you upload a preprocessed version of the gen-ust-events.c file for me to look at ?  (The tracepoint macro appears to lead into a twisty maze 
of include files which I am finding hard to follow).

Cheers
  Nick

Just to note - this is a gcc problem, not a binutils problem.

The gen-ust-events.c file includes an extremely long and complex inline assembler
statement, and the poor (gcc v4.8.5) compiler is unable to handle it.  A fix would be to use a newer compiler.  A workaround might be to break out the inline
assembler into its own assembler source file.

Cheers
  Nick

Created attachment 1162507 [details]
preprocessed gen-ust-events.i file

This is the preprocessed (intermediate) file for gen-ust-events.c

(In reply to Nick Clifton from comment #2)
> Just to note - this is a gcc problem, not a binutils problem.
> 
> The gen-ust-events.c file includes an extremely long and complex inline
> assembler
> statement, and the poor (gcc v4.8.5) compiler is unable to handle it.

Yet it builds on x86_64 and ppc64.

> A fix would be to use a newer compiler.

As an EPEL package, only the RHEL compiler can be used.

> A workaround might be to break out the inline assembler into its own assembler
> source file.

I don't think that's feasible, given that it is expanded from the lttng headers.

Andrew Haley suggested making the following change:

  +#pragma GCC optimize ("O1")
  +
   #define TRACEPOINT_DEFINE
   #include "tp.h"
   
   int
   main (int argc, char **argv)
   {

to tests/regression/tools/filtering/gen-ust-events.c

When I did this, I was able to build it in a mock environment without errors.

Please make this change so we can build for EPEL7 on AArch64.

Future versions of the systemtap sys/sdt.h file will include this explanatory blurb, which should help diagnose the problem:

/*
  This file defines a family of macros

       STAP_PROBEn(op1, ..., opn)

  that emit a nop into the instruction stream, and some data into an auxiliary
  note section.  The data in the note section describes the operands, in terms
  of size and location.  Each location is encoded as assembler operand string.
  Consumer tools such as gdb or systemtap insert breakpoints on top of
  the nop, and decode the location operand-strings, like an assembler,
  to find the values being passed.

  The operand strings are selected by the compiler for each operand.
  They are constrained by gcc inline-assembler codes.  The default is:

  #define STAP_SDT_ARG_CONSTRAINT nor

  This is a good default if the operands tend to be integral and
  moderate in number (smaller than number of registers).  In other
  cases, the compiler may report "'asm' requires impossible reload" or
  similar.  In this case, consider simplifying the macro call (fewer
  and simpler operands), reduce optimization, or override the default
  constraints string via:

  #define STAP_SDT_ARG_CONSTRAINT g
  #include <sys/sdt.h>

  See also:
  https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
  https://gcc.gnu.org/onlinedocs/gcc/Constraints.html
 */

Now that lttng-ust is building on AArch64 (rhbz#1319882), would it be possible to make the change mentioned in Comment 5 so lttng-tools will build as well.  I did a scratch build with a patch to make that change, and it completed successfully:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=16555739

Thanks D. Marlin!

Please feel free to push and build for EPEL 7.

I was just checking the later 2.4.1 Fedora builds, and found a similar issue had already been addressed for s390(x) using the following spec file change:

  %ifarch s390 s390x
  # workaround rhbz#837572 (ICE in gcc)
  %global optflags %(echo %{optflags} | sed 's/-O2/-O1/')
  %endif

Rather than add an aarch64 specific patch, I tried applying that change for AArch64 as well, and it successfully builds:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=16583151

If it's OK with you, I'll just push this change instead of the previously proposed patch, since it also works for AArch64 and has already been reviewed and approved for s390(x).

lttng-tools-2.4.1-5.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-fafacdd7b8

lttng-tools-2.4.1-5.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-fafacdd7b8

lttng-tools-2.4.1-5.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

lttng-tools-2.4.1-5.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.