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

clang compiler support for TuxML #36

Open
FAMILIAR-project opened this issue Jan 21, 2021 · 3 comments
Open

clang compiler support for TuxML #36

FAMILIAR-project opened this issue Jan 21, 2021 · 3 comments
Assignees

Comments

@FAMILIAR-project
Copy link
Collaborator

Instead of considering the gcc compiler, we'd like to consider clang.
What's missing is a complete support of clang in TuxML. In particular, we would like to compile random configurations with clang (over any kernel version).
It's challenging as the maturity of clang for the Linux kernel certainly differs than for gcc.
More details about the motivation here: https://www.youtube.com/watch?v=FFjV9f_Ub9o&t=10747s
We should experiment and report on our endeavour.

@alxvqold alxvqold self-assigned this Jan 27, 2021
@alxvqold
Copy link
Contributor

alxvqold commented Apr 14, 2021

I've started to implement Clang support in TuxML, but I won't have the time to continue working on it.

Kernel compilation only works for Clang 9+, i.e. the Clang versions that are available in Debian 11 Bullseye's repositories (packages clang-9 for Clang 9 and clang for Clang 11). That means that the compilations are done in the tuxml-gcc10 Docker image.

For now what I've done:

  • I added a __compiler_exec instance variable in compilation/compiler.py, which contains the command of the compiler to use ('gcc' for GCC, 'clang-9' for Clang 9 and 'clang' for Clang 11). This variable is used at every execution of make in compilation/compiler.py, as the argument for the CC parameter.
  • I added a --clang_version parameter in compilation/main.py, which for now supports either version numbers 9 or 11, or use GCC if another number is given without warning the user.

For now, the only way to use Clang is to call main.py from inside the tuxml-gcc10 Docker image with the --clang_version parameter set to 9 or 11.
The compilation's metadata have not been updated, and won't contain the Clang version. Instead the installed GCC version is showed.

These changes are added in the pull request #55.

To sum up, here is what has been done and what are the remaining tasks to have a Clang support in TuxML:

  • store the compiler's executable in an instance variable in compilation/compiler.py,
  • set a Clang version to use from compilation/main.py through an argument,
  • write the Clang version used instead of the installed GCC version in the compilation's metadata,
  • warn when a non-supported version of Clang is requested, or when a TuxML image that does not support Clang is used,
  • add Clang support to kernel_generator.py through the --compiler argument.

@acherm
Copy link
Collaborator

acherm commented Apr 14, 2021

Thanks!
Does clang-9 and clang already there in the Docker image tuxml-gcc10?
I guess no.

Can you write a small step-by-step tutorial on how to use your clang implementation and build a kernel? It would make it more actionable all explanations above.

@alxvqold
Copy link
Contributor

Packages clang and clang-9 are installed with other dependencies when building the Docker images.

What I have done to use Clang is to:

  • build the images with Clang support if not already done (sudo python3 docker_management/docker_image_tuxml.py),
  • compile a tiny kernel using GCC 10 to have an image with a specific Linux archive loaded (python3 kernel_generator.py --local --dev 1 --tiny --linux_version 5.8 --compiler gcc10),
  • log into the Docker image (docker run -it tuxml/tuxml-gcc10:dev-v5.8 /bin/bash),
  • ran a compilation with the --clang_version set (./TuxML/compilation/main.py --clang_version 11).

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

No branches or pull requests

3 participants