Bug 1614809
| Summary: | stap broken within devtoolset-6-perftools-docker container on top of a kernel with CONFIG_RETPOLINE=y | ||
|---|---|---|---|
| Product: | Red Hat Software Collections | Reporter: | Martin Cermak <mcermak> |
| Component: | doc-Using_RHSCL_Container_Images | Assignee: | Vladimír Slávik <vslavik> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Cermak <mcermak> |
| Severity: | low | Docs Contact: | Vladimír Slávik <vslavik> |
| Priority: | low | ||
| Version: | unspecified | CC: | emachado, fche, kanderso, lkuprova, lmanasko, mcermak, mnewsome, vslavik |
| Target Milestone: | rc | ||
| Target Release: | 3.1 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
*SystemTap* in `devtoolset-6-perftools` can not be used
The *SystemTap* tool requires the *GCC* compiler to be present as `/usr/bin/gcc`, and support retpolines. However, this is not the case in the `devtoolset-6-perftools` container. As a consequence, *SystemTap* in this container fails to run any script, and produces the following error message:
*** CONFIG_RETPOLINE=y, but not supported by the compiler.
As a result, *SystemTap* from `devtoolset-6-perftools` can not be used.
To work around this issue, install *GCC* in the container before running *SystemTap* :
# yum install gcc -y
# stap ...
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-08-29 07:39:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
That's correct, except for a question in the second point. Systemtap tries to use the -system- GCC, not some random DTS or other GCC to build modules. So, assuming that the system GCC is fine, the question is why a deficient gcc was being used by systemtap. Maybe that container lacked system gcc, and only had dts gcc in it? If so, that could give rise to other such problems in the future. An out-of-tree kernel module must be buildable with tools inside that container for full systemtap to work, which could mean having to get /usr/bin/gcc in there too, not just DTS. Anyway, just thinking out loud. Release notes could simply note that systemtap doesn't work in these containers due to an incompatibility between the container's dts gcc and the kernel. (In reply to Frank Ch. Eigler from comment #4) > Maybe that container lacked system gcc, and only had dts gcc in it? That's the case. And the kernel build system error message doesn't change even after removing devtoolset-6-gcc, so that there is no GCC on given system at all. OTOH installing /usr/bin/gcc does fix the problem. Any of gcc.rpm, or devtoolset-6-gcc.rpm satisfies the rpm depsolving need of devtoolset-6-systemtap-devel for GCC. > If so, > that could give rise to other such problems in the future. An out-of-tree > kernel module must be buildable with tools inside that container for full > systemtap to work, which could mean having to get /usr/bin/gcc in there too, > not just DTS. The devtoolset-7 docker image doesn't have this problem because devtoolset-7-systemtap-devel directly requires /usr/bin/gcc. And so does devtoolset-8-systemtap-devel. Chances are we won't hit this in the future. |
Here is what happens with systemtap within devtoolset-6-perftools-container-6-16 on top of a modern rhel-7 kernel with CONFIG_RETPOLINE=y: ======= [root@1b817717c146 ~]# gcc --version gcc (GCC) 6.3.1 20170216 (Red Hat 6.3.1-3) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [root@1b817717c146 ~]# stap -e 'probe begin{exit()}' arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y, but not supported by the compiler. Compiler update recommended.. Stop. WARNING: kbuild exited with status: 2 Pass 4: compilation failed. [man error::pass4] [root@1b817717c146 ~]# =======