Project

General

Profile

Actions

Bug #1344

closed

lttng-modules v2.11 package fails to build with a custom Linux Kernel build using Buildroot

Added by Sreedhar Mahadevan 6 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
Start date:
01/06/2022
Due date:
% Done:

0%

Estimated time:

Description

Hello,

I am not able to successfully build the lttng-modules package with Buildroot v2021.05. I get the following syntax errors:

output/build/lttng-modules-2.11.0/./probes/../instrumentation/events/lttng-module/timer.h:313:41: error: invalid use of undefined type ‘const struct itimerval’
313 | ctf_integer(long, interval_usec, value->it_interval.tv_usec) | ^~

output/build/lttng-modules-2.11.0/./lib/../lib/ringbuffer/frontend.h:82:6: error: implicit declaration of function ‘smp_read_barrier_depends’ [-Werror=implicit-function-declaration]
82 | smp_read_barrier_depends(); (cpu) < nr_cpu_ids; });) | ^~~~~~~~~~~~~~~~~~~~~~

/output/build/lttng-modules-2.11.0/./lib/../wrapper/trace-clock.h:168:3: error: implicit declaration of function ‘read_barrier_depends’ [-Werror=implicit-function-declaration]
168 | read_barrier_depends(); /* load ltc before content */ | ^~~~~~~~~~~~~~~~~~

The errors look mostly syntactical and is replicated with a fresh clone of v2021.08, v2021.11, v2020.05, v2020.08 also. The lttng-tools and lttng-babeltrace packages build without issues but the moment lttng-modules is selected and built, it fails. Is this issue known already? Are there any solutions for it?

I am attaching two .config files here. The reason is that I suspected the external tool chain option to create the issue, because of which I tried using buildroot's own tool chain. Unfortunately I encountered the same error using both configurations.


Files

.config_buildroot_2files.zip (40.8 KB) .config_buildroot_2files.zip Sreedhar Mahadevan, 01/06/2022 12:43 AM
Actions #1

Updated by Sreedhar Mahadevan 6 months ago

Would like to update one development from my end. I cloned the lttng-modules package directly from its Github repository: https://github.com/lttng/lttng-modules

From this lttng-modules environment, I tried building lttng-modules v2.13.0 based on the instructions in its README.md file by referencing the custom linux version that I was using (v5.10.x corresponding to Buildroot v2021.05) and it built successfully. When I tried building lttng-modules v2.12.0 and v2.11.0 and I got the exact error which I encountered in the Buildroot environment (reported earlier in this bug report). I see that buildroot v2021.08 and 2021.11 all continue using lttng-modules v2.11.0 and all seem to have the same issue.

Is this possibly the reason for the issue? If yes, how do I solve it? I tried hacking into the buildroot/package/lttng-modules/lttng-modules.mk and lttng-modules.hash files but I still faced issues with the wrong sha256 hashes. Can you please help?

Actions #2

Updated by Jonathan Rajotte Julien 6 months ago

  • Status changed from New to Feedback
  • Priority changed from Critical to Normal

Hi,

lttng-modules must follow kernel changes hence you need to use at least the latest patch level release of a stable version if you want maximum compatibility in regards to supported kernels.

From a quick git history search I suppose that the patch that address this problem is:

ommit 21ed5ea7e16fcce1cf1169b8e953e6d02ad531c9
Author: Michael Jeanson <mjeanson@efficios.com>
Date:   Tue Aug 25 10:56:29 2020 -0400

    fix: removal of [smp_]read_barrier_depends (v5.9)

    See upstream commits:

      commit 76ebbe78f7390aee075a7f3768af197ded1bdfbb
      Author: Will Deacon <will@kernel.org>
      Date:   Tue Oct 24 11:22:47 2017 +0100

        locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()

        In preparation for the removal of lockless_dereference(), which is the
        same as READ_ONCE() on all architectures other than Alpha, add an
        implicit smp_read_barrier_depends() to READ_ONCE() so that it can be
        used to head dependency chains on all architectures.

      commit 76ebbe78f7390aee075a7f3768af197ded1bdfbb
      Author: Will Deacon <will.deacon@arm.com>
      Date:   Tue Oct 24 11:22:47 2017 +0100

        locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()

        In preparation for the removal of lockless_dereference(), which is the
        same as READ_ONCE() on all architectures other than Alpha, add an
        implicit smp_read_barrier_depends() to READ_ONCE() so that it can be
        used to head dependency chains on all architectures.

    Change-Id: Ife8880bd9378dca2972da8838f40fc35ccdfaaac
    Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
    Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Note that this patch is available (for the stable 2.11 branch) in:

joraj@~/lttng/master/lttng-modules [(45fe4e1a...)][]$ git tag --contains 21ed5ea7e16fcce1cf1169b8e953e6d02ad531c9
v2.11.6
v2.11.7
v2.11.8
v2.11.9

On 2.12.x it is available since:

joraj@~/lttng/stable-2.12/lttng-modules [master][]$ git tag --contains 57ccbfa6a8a79c7b84394c2097efaf7935607aa5
v2.12.3
v2.12.4
v2.12.5
v2.12.6
v2.12.7

Please upgrade lttng-modules to the latest available patch level release for the stable branch off your desire.

I'm no buildroot expert but it should be quite straight forward to change lttng-modules.mk and lttng-modules.hash

lttng-modules.mk:

LTTNG_MODULES_VERSION = 2.11.9

lttng-modules.hash

0c5fe9f8d8dbd1411a3c1c643dcbd0a55577bd15845758b73948e00bc7c387a6  lttng-modules-2.11.9.tar.bz2

Based on this update commit: https://github.com/buildroot/buildroot/commit/67ffe1f2a55140c1171b1afd596fb7b86595c82b to 2.11.0.

If this does not work, I suppose that reaching out to the package maintainers of the lttng-modules builroot package would be the next step to get some guidance.

Cheers

Actions #3

Updated by Sreedhar Mahadevan 6 months ago

Thanks a lot for the response. I shall try it out and give a feedback.

Actions #4

Updated by Sreedhar Mahadevan 6 months ago

Thanks once again. I was able to use lttng-modules with the changes to 2.11.9 in the .mk and .hash files.
Thanks a lot for the timely support.

Actions #5

Updated by Jonathan Rajotte Julien 6 months ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF