uftrace
uftrace copied to clipboard
namhyung
uftrace cannot be compiled by clang-9 with DEBUG=1
uftrace is able to be compiled with clang-9, but fails when DEBUG=1 is given.
$ CC=clang-9 ./configure
$ make DEBUG=1
CC FPIC libmcount/script-python.op
Stack dump:
0. Program arguments: /usr/lib/llvm-9/bin/clang -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name script-python.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-feature -sse2 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -coverage-notes-file /home/honggyu/work/uftrace/libmcount/script-python.gcno -resource-dir /usr/lib/llvm-9/lib/clang/9.0.1 -iquote /home/honggyu/work/uftrace -iquote /home/honggyu/work/uftrace -iquote /home/honggyu/work/uftrace/arch/x86_64 -D _GNU_SOURCE -D HAVE_CXA_DEMANGLE -D HAVE_LIBPYTHON3 -I /usr/include/python3.8 -D LIBPYTHON_VERSION=3.8 -D HAVE_LIBLUAJIT -I /usr/include/luajit-2.0 -D HAVE_PERF_CLOCKID -D HAVE_PERF_CTXSW -D HAVE_LIBNCURSES -D _GNU_SOURCE -I /usr/include/ncursesw -D HAVE_LIBELF -D HAVE_LIBDW -D HAVE_LIBCAPSTONE -I /usr/include/capstone -internal-isystem /usr/local/include -internal-isystem /usr/lib/llvm-9/lib/clang/9.0.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O0 -Wdeclaration-after-statement -W -Wall -Wno-unused-parameter -Wno-missing-field-initializers -fdebug-compilation-dir /home/honggyu/work/uftrace -ferror-limit 19 -fmessage-length 0 -fvisibility hidden -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o /home/honggyu/work/uftrace/libmcount/script-python.op -x c /home/honggyu/work/uftrace/utils/script-python.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module '/home/honggyu/work/uftrace/utils/script-python.c'.
4. Running pass 'X86 FP Stackifier' on function '@insert_tuple_double'
#0 0x00007fb1e9c702cf llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xa342cf)
#1 0x00007fb1e9c6e6f0 llvm::sys::RunSignalHandlers() (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xa326f0)
#2 0x00007fb1e9c706d1 (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xa346d1)
#3 0x00007fb1ef889390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#4 0x00007fb1eb86a43e (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0x262e43e)
#5 0x00007fb1eb8694dc (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0x262d4dc)
#6 0x00007fb1e9ef3728 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xcb7728)
#7 0x00007fb1e9d6e096 llvm::FPPassManager::runOnFunction(llvm::Function&) (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xb32096)
#8 0x00007fb1e9d6e343 llvm::FPPassManager::runOnModule(llvm::Module&) (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xb32343)
#9 0x00007fb1e9d6e7f0 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/lib/x86_64-linux-gnu/libLLVM-9.so.1+0xb327f0)
#10 0x00007fb1ee622706 EmitAssembly /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/CodeGen/BackendUtil.cpp:899:3
#11 0x00007fb1ee622706 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/CodeGen/BackendUtil.cpp:1498:15
#12 0x00007fb1ee856a3d ~unique_ptr /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/unique_ptr.h:235:6
#13 0x00007fb1ee856a3d HandleTranslationUnit /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/CodeGen/CodeGenAction.cpp:303:7
#14 0x00007fb1edb96d33 __normal_iterator /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/stl_iterator.h:741:20
#15 0x00007fb1edb96d33 begin /usr/lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/bits/stl_vector.h:548:16
#16 0x00007fb1edb96d33 finalize<std::vector<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> >, std::allocator<std::unique_ptr<clang::TemplateInstantiationCallback, std::default_delete<clang::TemplateInstantiationCallback> > > > > /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/include/clang/Sema/TemplateInstCallback.h:54:16
#17 0x00007fb1edb96d33 clang::ParseAST(clang::Sema&, bool, bool) /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/Parse/ParseAST.cpp:178:3
#18 0x00007fb1eee22778 clang::FrontendAction::Execute() /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/Frontend/FrontendAction.cpp:938:10
#19 0x00007fb1eede5650 getPtr /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/llvm/include/llvm/Support/Error.h:273:42
#20 0x00007fb1eede5650 operator bool /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/llvm/include/llvm/Support/Error.h:236:16
#21 0x00007fb1eede5650 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/Frontend/CompilerInstance.cpp:944:23
#22 0x00007fb1eee844c0 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /build/llvm-toolchain-9-9~+20191211110317+c1a0a213378/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:291:25
#23 0x0000000000498254 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/llvm-9/bin/clang+0x498254)
#24 0x0000000000496a21 main (/usr/lib/llvm-9/bin/clang+0x496a21)
#25 0x00007fb1e858e830 __libc_start_main /build/glibc-LK5gWL/glibc-2.23/csu/../csu/libc-start.c:325:0
#26 0x0000000000493e89 _start (/usr/lib/llvm-9/bin/clang+0x493e89)
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 9.0.1-+20191211110317+c1a0a213378-1~exp1~20191211221711.104
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/script-python-17ada5.c
clang: note: diagnostic msg: /tmp/script-python-17ada5.sh
clang: note: diagnostic msg:
********************
Makefile:230: recipe for target '/home/honggyu/work/uftrace/libmcount/script-python.op' failed
make: *** [/home/honggyu/work/uftrace/libmcount/script-python.op] Error 254
It compiles without the problem when python scripting is off.
CC=clang-9 ./configure --without-libpython
I see that the compilation error comes from insert_tuple_double function so it compiles fine if it's not called with the change below.
diff --git a/utils/script-python.c b/utils/script-python.c
index 221d55ea..157eca1a 100644
--- a/utils/script-python.c
+++ b/utils/script-python.c
@@ -477,7 +477,6 @@ static void setup_argument_context(PyObject **pDict, bool is_retval,
dval = 0;
break;
}
- insert_tuple_double(args, count++, dval);
data += ALIGN(spec->size, 4);
break;
It's very weird but we cannot pass double type in the argument.
diff --git a/utils/script-python.c b/utils/script-python.c
index 221d55ea..302efed5 100644
--- a/utils/script-python.c
+++ b/utils/script-python.c
@@ -351,10 +351,8 @@ static void insert_tuple_string(PyObject *tuple, int idx, char *v)
python_insert_tuple(tuple, 's', idx, val);
}
-static void insert_tuple_double(PyObject *tuple, int idx, double v)
+static void insert_tuple_double(double v)
{
- union python_val val = { .f = v, };
- python_insert_tuple(tuple, 'f', idx, val);
}
static void insert_dict_long(PyObject *dict, const char *key, long v)
@@ -477,7 +475,7 @@ static void setup_argument_context(PyObject **pDict, bool is_retval,
dval = 0;
break;
}
- insert_tuple_double(args, count++, dval);
+ insert_tuple_double(dval);
data += ALIGN(spec->size, 4);
break;
The above problem still shows the same error. Maybe it might be a clang internal error so it could be useful if we can avoid this code pattern.
It's also very weird that the following compiles fine.
diff --git a/utils/script-python.c b/utils/script-python.c
index 221d55ea..117449bd 100644
--- a/utils/script-python.c
+++ b/utils/script-python.c
@@ -351,7 +351,7 @@ static void insert_tuple_string(PyObject *tuple, int idx, char *v)
python_insert_tuple(tuple, 's', idx, val);
}
-static void insert_tuple_double(PyObject *tuple, int idx, double v)
+static void insert_tuple_double(PyObject *tuple, int idx, float v)
{
union python_val val = { .f = v, };
python_insert_tuple(tuple, 'f', idx, val);
@@ -477,7 +477,7 @@ static void setup_argument_context(PyObject **pDict, bool is_retval,
dval = 0;
break;
}
- insert_tuple_double(args, count++, dval);
+ insert_tuple_double(args, count++, (float)dval);
data += ALIGN(spec->size, 4);
break;
The following change makes a different clang error.
diff --git a/utils/script-python.c b/utils/script-python.c
index 221d55ea..c8a00bc6 100644
--- a/utils/script-python.c
+++ b/utils/script-python.c
@@ -351,7 +351,7 @@ static void insert_tuple_string(PyObject *tuple, int idx, char *v)
python_insert_tuple(tuple, 's', idx, val);
}
-static void insert_tuple_double(PyObject *tuple, int idx, double v)
+void insert_tuple_double(PyObject *tuple, int idx, double v)
{
union python_val val = { .f = v, };
python_insert_tuple(tuple, 'f', idx, val);
It shows
$ make DEBUG=1
CC utils/script-python.o
LINK uftrace
CC FPIC libmcount/script-python.op
fatal error: error in backend: Access past stack top!
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 9.0.1-+20191211110317+c1a0a213378-1~exp1~20191211221711.104
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/script-python-a45f98.c
clang: note: diagnostic msg: /tmp/script-python-a45f98.sh
clang: note: diagnostic msg:
********************
If we can avoid this problem, then maybe we can enable clang build in our CI by default.
Maybe uftrace doesn't go well with floating point handling compiled by clang as reported at https://github.com/namhyung/uftrace/issues/1116#issuecomment-699471831.
I know it's very weird, but the following change makes clang happy to compile it.
diff --git a/utils/script-python.c b/utils/script-python.c
index 221d55ea..ff192534 100644
--- a/utils/script-python.c
+++ b/utils/script-python.c
@@ -351,9 +351,15 @@ static void insert_tuple_string(PyObject *tuple, int idx, char *v)
python_insert_tuple(tuple, 's', idx, val);
}
-static void insert_tuple_double(PyObject *tuple, int idx, double v)
+/*
+ * xxx: There might be a clang internal error so cannot compile the following
+ * function, which originally accept double type argument as call by value.
+ * It's because of having double type argument in this specific case.
+ * So 'double v' is changed to accept 'double *v' to avoid this problem.
+ */
+static void insert_tuple_double(PyObject *tuple, int idx, double *v)
{
- union python_val val = { .f = v, };
+ union python_val val = { .f = *v, };
python_insert_tuple(tuple, 'f', idx, val);
}
@@ -477,7 +483,7 @@ static void setup_argument_context(PyObject **pDict, bool is_retval,
dval = 0;
break;
}
- insert_tuple_double(args, count++, dval);
+ insert_tuple_double(args, count++, &dval);
data += ALIGN(spec->size, 4);
break;
It shows the similar build error in the latest trunk of clang. the reproducible file and script is attached as follows.
The LLVM bug report is uploaded at https://bugs.llvm.org/show_bug.cgi?id=47961 and the tested hash version is https://github.com/llvm/llvm-project/commit/f81f09ba8950a199af88e5a622155fb9801b11b7.
It's not fixed yet, but the bugzilla issue was transferred to https://github.com/llvm/llvm-project/issues/47305.