Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add BPF GCC support for BPF CI #144

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

cupermir
Copy link

This PR adds support for building BPF GCC for the purpose to integrate it in BPF CI.

Similar support that makes use of this code will be pull requested in kernel-patches/bpf repo.

Copy link
Collaborator

@chantra chantra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @cupermir .

Overall, LGTM. In order to be able to test this self-isolate, would you mind adding an entry in

toolchain:
to exercise the gcc bpf-toolchain install/run?

I am actually wondering if this will uncover that it is also needed as part of the testing environment? In which case, during the test run we would need to install the toolchain again.

source $(cd $(dirname $0) && pwd)/../helpers.sh

LOGFILE=build-gnu-bpf.log
INSTALLDIR=$(pwd)/install_bpf_gcc/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have mixed filling about using pwd here. It is probably better to stick to ${GITHUB_WORKSPACE} here so it is consistently at the same location and not dependent on the current working directory the workflow is running the action in.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.
Please notice that the source $(cd $(dirname $0) && pwd)/../helpers.sh is already in setup-build-env/install_clang.sh.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. This is fine. I meant this comment for INSTALL_DIR. The former is basically to build a path to the helper file in repo, regardless of the working directory.


ARCH="$(platform_to_kernel_arch ${TARGET_ARCH})"
CROSS_COMPILE=""
BPF_GCC_BIN="$(pwd)/install_bpf_gcc/bin/bpf-unknown-none-gcc"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here regarding $(pwd)

@cupermir
Copy link
Author

toolchain:

to exercise the gcc bpf-toolchain install/run?

I am actually wondering if this will uncover that it is also needed as part of the testing environment? In which case, during the test run we would need to install the toolchain again.

If I understand well what is happening in test.yml, there is nothing to be added to it, since the bpf-gcc this PR instroduces is only a bpf compiler, it would not impact kernel building in any way.

Copy link
Collaborator

@chantra chantra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toolchain:

to exercise the gcc bpf-toolchain install/run?
I am actually wondering if this will uncover that it is also needed as part of the testing environment? In which case, during the test run we would need to install the toolchain again.

If I understand well what is happening in test.yml, there is nothing to be added to it, since the bpf-gcc this PR instroduces is only a bpf compiler, it would not impact kernel building in any way.

The test.yml file here builds (kernel and selftests) and run the tests. If your diff was adding an the right bpf-toolchain metadata to the toolchain matrix, you could get the testing to actually exercise building selftests with GCC.

the test.yml file is calling "reusable" workflows that thenselves take inputs, which are provided in https://github.com/libbpf/ci/blob/main/.github/workflows/test.yml#L33 and used in the reusable workflow https://github.com/libbpf/ci/blob/main/.github/workflows/kernel-build-test.yml (which IIRC, also calls other reusable workflow).

#!/bin/bash
set -eu

source $(cd $(dirname $0) && ${GITHUB_WORKSPACE})/../helpers.sh
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was correctly using $(pwd). This line essentially used to be able to find the helpers.sh file in the parent directory of this script. There is no warranty, and likely is is never going to be, in the parent directory of GITHUB_WORKSPACE.

Currently, this code is not ran because we do not bpf-toolchain is not set in the test cases.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just patched the pwd regression.

Currently, this code is not ran because we do not bpf-toolchain is not set in the test cases.

Honestly, I would not know where to start to add it in.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

toolchain:
- {"name": "gcc", "fullname": "gcc", "version": 17}
- {"name": "llvm", "fullname": "llvm-17", "version": 17}
tests: [{"include": [{"test": "test_progs", "continue_on_error": false, "timeout_minutes": 360}, {"test": "test_progs_no_alu32", "continue_on_error": false, "timeout_minutes": 360}, {"test": "test_verifier", "continue_on_error": false, "timeout_minutes": 360}, {"test": "test_maps", "continue_on_error": false, "timeout_minutes": 360}]}]

This is where you would want to modify the current entries to have the bpf-toolchain set to whatever the default is, and add an entry where bpf-toolchain is set to GCC.

You will then need to pass the toolchain through the with statement:

and probably need to propagate it in the reusable workflows that are indirectly used.

https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow#using-a-matrix-strategy may help in understanding how this works.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, you also need to run a separate set of tests for gcc, so you may need more tweaking.

Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants