Bug 1614809 - stap broken within devtoolset-6-perftools-docker container on top of a kernel with CONFIG_RETPOLINE=y
Summary: stap broken within devtoolset-6-perftools-docker container on top of a kernel...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Software Collections
Classification: Red Hat
Component: doc-Using_RHSCL_Container_Images
Version: unspecified
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: 3.1
Assignee: Vladimír Slávik
QA Contact: Martin Cermak
Vladimír Slávik
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-10 13:02 UTC by Martin Cermak
Modified: 2018-08-29 07:39 UTC (History)
8 users (show)

(edit)
*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 ...
Clone Of:
(edit)
Last Closed: 2018-08-29 07:39:16 UTC


Attachments (Terms of Use)

Description Martin Cermak 2018-08-10 13:02:02 UTC
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 ~]#                                                             
=======

Comment 4 Frank Ch. Eigler 2018-08-13 18:15:47 UTC
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.

Comment 5 Martin Cermak 2018-08-14 06:56:42 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.