fxregs.c undefined reference to __x86.get_pc_thunk.ax while building on CENTOS7
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c, cmake
- Domain
- build-system, operating-systems
Research direction
Reproduce the 32-bit build from 32/x86/fxregs.c on CentOS 7.8 with GCC 4.8.5, first using the reported configuration and then with disable32bit enabled for comparison. Inspect the inline assembly around the __x86.get_pc_thunk.ax call and verify that the 32-bit target links successfully without that undefined reference.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- C++
- Stars
- 10.7k
- Forks
- 662
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 2
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rr-debugger/rr
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
rr-debugger/rr#4096 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rr-debugger/rr#4093 · 6 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rr-debugger/rr#4090 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
rr-debugger/rr#4060 · 5 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
rr-debugger/rr#4059 · 1 comment ·
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·