rr icon indicating copy to clipboard operation
rr copied to clipboard

fxregs.c undefined reference to __x86.get_pc_thunk.ax while building on CENTOS7

Open jalapenopuzzle opened this issue 4 years ago • 9 comments

I tried building rr at commit b04220a6e66c2f9f47c9c953b928ce074bf6c075 on CENTOS 7.8 using gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44).

[ben@rr obj]$ cmake3 ../rr
-- The C compiler identification is GNU 4.8.5
-- The CXX compiler identification is GNU 4.8.5
-- The ASM compiler identification is GNU
-- Found assembler: /usr/lib64/ccache/cc
-- Check for working C compiler: /usr/lib64/ccache/cc
-- Check for working C compiler: /usr/lib64/ccache/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test SUPPORTS_CXX14
-- Performing Test SUPPORTS_CXX14 - Failed
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.27.1") 
-- Checking for module 'capnp'
--   Found capnp, version 0.5.3.1
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.8", minimum required is "3") 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ben/rr/obj
[ben@rr obj]$ make
...
Scanning dependencies of target fxregs_32
[  5%] Building C object CMakeFiles/fxregs_32.dir/32/x86/fxregs.c.o
[  5%] Linking C executable bin/fxregs_32
CMakeFiles/fxregs_32.dir/32/x86/fxregs.c.o: In function `main':
/home/ben/rr/obj/32/x86/fxregs.c:64: undefined reference to `__x86.get_pc_thunk.ax'
collect2: error: ld returned 1 exit status
make[2]: *** [bin/fxregs_32] Error 1
make[1]: *** [CMakeFiles/fxregs_32.dir/all] Error 2
make: *** [all] Error 2
[ben@rr obj]$

It seems that fxregs.c is calling __x86.get_pc_thunk.ax , but it is not available. Reading around, this seems to be provided by some versions of gcc, but it seems very unwise to depend on it. Unfortunately I have not come to a good understanding of it.

From fxregs.c:

int main(void) {
  unsigned int eax, ecx, edx;
  unsigned int required_cpuid_flags = AVX_FEATURE_FLAG | OSXSAVE_FEATURE_FLAG;

  cpuid(CPUID_GETFEATURES, 0, &eax, &ecx, &edx);
  AVX_enabled = (ecx & required_cpuid_flags) == required_cpuid_flags;

  if (!AVX_enabled) {
    atomic_puts("AVX YMM registers disabled, not tested");
  }

  __asm__ __volatile__(
/* Push the constants in stack order so they look as
 * we expect in gdb. */
#if __i386__
      "call __x86.get_pc_thunk.ax\n\t"
      "addl $_GLOBAL_OFFSET_TABLE_, %eax\n\t"
      "fldl st7@GOTOFF(%eax)\n\t"
      "fldl st6@GOTOFF(%eax)\n\t"
      "fldl st5@GOTOFF(%eax)\n\t"
      "fldl st4@GOTOFF(%eax)\n\t"
      "fldl st3@GOTOFF(%eax)\n\t"
      "fldl st2@GOTOFF(%eax)\n\t"
      "fldl st1@GOTOFF(%eax)\n\t"
      "fldl st0@GOTOFF(%eax)\n\t"
      "movss xmm0@GOTOFF(%eax), %xmm0\n\t"
      "movss xmm1@GOTOFF(%eax), %xmm1\n\t"
      "movss xmm2@GOTOFF(%eax), %xmm2\n\t"
      "movss xmm3@GOTOFF(%eax), %xmm3\n\t"
      "movss xmm4@GOTOFF(%eax), %xmm4\n\t"
      "movss xmm5@GOTOFF(%eax), %xmm5\n\t"
      "movss xmm6@GOTOFF(%eax), %xmm6\n\t"
      "movss xmm7@GOTOFF(%eax), %xmm7\n\t"
#elif __x86_64__

It seems that the problem can be avoided by disabling 32 bit support:

[ben@rr obj]$ cmake3 ../rr -Ddisable32bit=ON

Unfortunately I still have a use for rr on 32 bit.

Can the dependence on __x86.get_pc_thunk.ax be removed from the 32 bit build?

jalapenopuzzle avatar Jul 15 '21 09:07 jalapenopuzzle

Do I just need to build it with a newer GCC?

jalapenopuzzle avatar Jul 15 '21 09:07 jalapenopuzzle

Install Developer Toolset 7 [1] and enable it before building to work around this problem on CENTOS7.

sudo yum install centos-release-scl
sudo yum install devtoolset-7
cd obj
[ben@rr obj]$ scl enable devtoolset-7 bash
[ben@rr obj]$ cmake3 ../rr
-- The C compiler identification is GNU 7.3.1
-- The CXX compiler identification is GNU 7.3.1
-- The ASM compiler identification is GNU
-- Found assembler: /opt/rh/devtoolset-7/root/usr/bin/cc
-- Check for working C compiler: /opt/rh/devtoolset-7/root/usr/bin/cc
-- Check for working C compiler: /opt/rh/devtoolset-7/root/usr/bin/cc - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/rh/devtoolset-7/root/usr/bin/c++
-- Check for working CXX compiler: /opt/rh/devtoolset-7/root/usr/bin/c++ - works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test SUPPORTS_CXX14
-- Performing Test SUPPORTS_CXX14 - Success
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.27.1") 
-- Checking for module 'capnp'
--   Found capnp, version 0.5.3.1
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.6.8", minimum required is "3") 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ben/rr/obj
[ben@rr obj]$ make
...
Scanning dependencies of target fxregs_32
[  5%] Building C object CMakeFiles/fxregs_32.dir/32/x86/fxregs.c.o
[  5%] Linking C executable bin/fxregs_32
[  5%] Built target fxregs_32
...

Unfortunately I now have other problems later in the build which I will open separate issues for.

To resolve this issue, the documentation should be updated to include a build procedure for CENTOS7.

[1] https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/

jalapenopuzzle avatar Jul 15 '21 09:07 jalapenopuzzle

Unfortunately it is not possible to build rr in 32 bit mode using devtoolset 7, 8, 9 on CENTOS7 because the following packages are not available in CENTOS7 SCL: devtoolset-7-libstdc++-devel.i686 devtoolset-8-libstdc++-devel.i686 devtoolset-9-libstdc++-devel.i686 These packages are available in RHEL see https://access.redhat.com/errata/RHEA-2019:4134 Therefore it may be possible to build rr 32 bit on RHEL.

Related: https://stackoverflow.com/questions/60229740/how-do-i-build-32-bit-binaries-with-red-hat-developer-toolset https://bugzilla.redhat.com/show_bug.cgi?id=1642077

This has been reported to CENTOS: https://bugs.centos.org/view.php?id=16181

jalapenopuzzle avatar Jul 15 '21 12:07 jalapenopuzzle

You could disable building the tests (e.g. cmake -DBUILD_TESTS=OFF)

khuey avatar Jul 26 '21 00:07 khuey

I can fix this problem by compiling with a newer gcc from rhscl devtoolset-7. But then other problems are revealed. WIP.

On 26 July 2021 10:20:04 am Kyle Huey @.***> wrote:

You could disable building the tests (e.g. cmake -DBUILD_TESTS=OFF) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

jalapenopuzzle avatar Jul 26 '21 00:07 jalapenopuzzle

Works for me with current master without additional tools installed using CC=gcc cmake3 -Ddisable32bit=ON ../rr.

GitMensch avatar Dec 03 '21 15:12 GitMensch

That was observed early on - see comment https://github.com/rr-debugger/rr/issues/2927#issue-945160830

Can you make it work with 32 bit support enabled?

On 4 December 2021 2:55:07 am Simon Sobisch @.***> wrote:

Works for me with current master without additional tools installed using CC=gcc cmake3 -Ddisable32bit=ON ../rr. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

jalapenopuzzle avatar Dec 03 '21 19:12 jalapenopuzzle

Sorry, I've missed the 32bit part. I think I've once got it building with 32 bit once (I guess that as over a year ago), maybe CC=gcc was enough for this - but since I've seen that we don't need to record/replay any 32bit I've dropped that for faster builds and smaller size.

GitMensch avatar Dec 03 '21 21:12 GitMensch

Regrettably I still have to support 32 bit stuff so this option remains important to me.

On 4 December 2021 8:24:15 am Simon Sobisch @.***> wrote:

Sorry, I've missed the 32bit part. I think I've once got it building with 32 bit once (I guess that as over a year ago), maybe CC=gcc was enough for this - but since I've seen that we don't need to record/replay any 32bit I've dropped that for faster builds and smaller size. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

jalapenopuzzle avatar Dec 03 '21 22:12 jalapenopuzzle