Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py
Hi Pavel, Thank you for the fix and for taking care of this! So, the particular test binary is: ScriptInterpreterPythonTests . And here is the link command: ) ninja ScriptInterpreterPythonTests -v [1/1] : && /usr/lib/ccache/clang++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3 -Wl,-allow-shlib-undefined -Wl,-O3 -Wl,--gc-sections tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonDataObjectsTests.cpp.o tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonExceptionStateTests.cpp.o tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o -o tools/lldb/unittests/ScriptInterpreter/Python/ScriptInterpreterPythonTests -Wl,-rpath,/home/egbomrt/WORK/llvm3/build/release_assert/lib -lpthread lib/libgtest_main.so.7svn lib/libgtest.so.7svn -lpthread lib/liblldbHost.a lib/liblldbPluginScriptInterpreterPython.a /usr/lib/x86_64-linux-gnu/ libpython2.7.so lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a lib/libLLVMDemangle.so.7svn lib/libclangFrontend.so.7svn lib/libLLVMExecutionEngine.so.7svn lib/libLLVMObject.so.7svn lib/libLLVMCore.so.7svn lib/libLLVMRuntimeDyld.so.7svn lib/libclangCodeGen.so.7svn lib/libclangDriver.so.7svn lib/libclangEdit.so.7svn lib/libclangParse.so.7svn lib/libclangRewrite.so.7svn lib/libclangRewriteFrontend.so.7svn lib/libclangSema.so.7svn lib/libclangSerialization.so.7svn lib/libLLVMipo.so.7svn lib/libLLVMMCJIT.so.7svn lib/libclangBasic.so.7svn lib/libLLVMDebugInfoDWARF.so.7svn lib/libclangLex.so.7svn lib/libLLVMDebugInfoPDB.so.7svn lib/liblldbBase.a lib/liblldbUtility.a lib/libLLVMSupport.so.7svn -lpthread /usr/lib/x86_64-linux-gnu/ libpython2.7.so /usr/lib/x86_64-linux-gnu/libxml2.so -ldl -ledit -lcurses /usr/lib/x86_64-linux-gnu/libform.so /usr/lib/x86_64-linux-gnu/libpanel.so -ltinfo lib/libLLVMBinaryFormat.so.7svn lib/libclangAST.so.7svn -Wl,-rpath-link,/home/egbomrt/WORK/llvm3/build/release_assert/lib && cd /home/egbomrt/WORK/llvm3/build/release_assert/tools/lldb/unittests/ScriptInterpreter/Python && /usr/local/bin/cmake -E make_directory /home/egbomrt/WORK/llvm3/build/release_assert/tools/lldb/unittests/ScriptInterpreter/Python/./Inputs Let me know if there is any additional info you need, Gabor On Thu, Jun 28, 2018 at 4:45 PM Pavel Labath wrote: > The core file tests should be fixed as of r335859. I tried reproing > the python unit tests problem, but I couldn't get it to fail that way. > I can help you get to the bottom of it if you're interested, but it's > goi
[lldb-dev] London LLVM Social Thursday July 19
Hi everyone, We’re excited to invite you to the second LLVM social in London on Thursday, July 19. We'll meet at Drake & Morgan (6 Pancras Square, Kings Cross, N1C 4AG) at 6:30 pm for an informal evening of LLVM-related discussions over drinks. If you can, please help us plan and RSVP here: https://www.meetup.com/LLVM-Clang-Cambridge-social/events/252228264/ Cheers, Jonas ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py
Hi Gábor, thanks for sending me that link line. Unfortunately, I don't see anything immediately obvious there. (I was expecting there would be something pulling in LLVMSupport twice, but I don't see anything like that there). To fix this, we need to figure out where is the second definition of this option is coming from (the first one should be in libLLVMSupport.so). After that, it should be relatively straightforward to fix the cmake project to avoid that. The variable declaring this command option is called HLOp (in CommandLine.cpp), so one of the ways to do that is to make find that out is to search for the _ZL4HLOp symbol in the symtab of the shared libraries (you should not even need debug info for that). Can you check which of the libraries in your build folder contain this symbol? On Fri, 29 Jun 2018 at 09:13, Gábor Márton wrote: > > Hi Pavel, > > Thank you for the fix and for taking care of this! > So, the particular test binary is: ScriptInterpreterPythonTests . > And here is the link command: > ) ninja ScriptInterpreterPythonTests -v > [1/1] : && /usr/lib/ccache/clang++ -fPIC -fvisibility-inlines-hidden > -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter > -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic > -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor > -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color > -ffunction-sections -fdata-sections -Wno-deprecated-declarations > -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register > -Wno-vla-extension -O3 -Wl,-allow-shlib-undefined -Wl,-O3 > -Wl,--gc-sections > tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonDataObjectsTests.cpp.o > > tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonExceptionStateTests.cpp.o > > tools/lldb/unittests/ScriptInterpreter/Python/CMakeFiles/ScriptInterpreterPythonTests.dir/PythonTestSuite.cpp.o > -o > tools/lldb/unittests/ScriptInterpreter/Python/ScriptInterpreterPythonTests > -Wl,-rpath,/home/egbomrt/WORK/llvm3/build/release_assert/lib -lpthread > lib/libgtest_main.so.7svn lib/libgtest.so.7svn -lpthread lib/liblldbHost.a > lib/liblldbPluginScriptInterpreterPython.a > /usr/lib/x86_64-linux-gnu/libpython2.7.so lib/liblldbHost.a lib/liblldbCore.a > lib/liblldbSymbol.a lib/liblldbTarget.a lib/liblldbBreakpoint.a > lib/liblldbDataFormatters.a lib/liblldbInterpreter.a lib/liblldbExpression.a > lib/liblldbPluginProcessUtility.a lib/liblldbPluginCPlusPlusLanguage.a > lib/liblldbPluginObjCLanguage.a lib/liblldbPluginExpressionParserClang.a > lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a > lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a > lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a > lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a > lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a > lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a > lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a > lib/liblldbPluginExpressionParserClang.a > lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a > lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a > lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a > lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a > lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a > lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a > lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a > lib/liblldbPluginExpressionParserClang.a > lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a > lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a > lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a > lib/liblldbHost.a lib/liblldbCore.a lib/liblldbSymbol.a lib/liblldbTarget.a > lib/liblldbBreakpoint.a lib/liblldbDataFormatters.a lib/liblldbInterpreter.a > lib/liblldbExpression.a lib/liblldbPluginProcessUtility.a > lib/liblldbPluginCPlusPlusLanguage.a lib/liblldbPluginObjCLanguage.a > lib/liblldbPluginExpressionParserClang.a > lib/liblldbPluginExpressionParserGo.a lib/liblldbPluginSymbolFileDWARF.a > lib/liblldbPluginSymbolFilePDB.a lib/liblldbCommands.a > lib/liblldbPluginObjectFileJIT.a lib/liblldbPluginAppleObjCRuntime.a > lib/libLLVMDemangle.so.7svn lib/libclangFrontend.so.7svn > lib/libLLVMExecutionEngine.so.7svn lib/libLLVMObject.so.7svn > lib/libLLVMCore.so.7svn lib/libLLVMRuntimeDyld.so.7svn > lib/libclangCodeGen.so.7svn lib/libclangDriver.so.7svn > lib/libclangEdit.so.7svn lib/libclangParse.so.7svn > lib/libclangRewrite.so.7svn lib/libclangRewriteFrontend.so.7svn > lib/libclangSema.so.7svn lib/libclangSerialization.so.7svn > lib/libLLVMipo.so.7svn lib/libLLVMMCJIT.so.7svn lib/libclangBasic.so.7svn > li
[lldb-dev] [Bug 37986] New: Segmentation fault (core dumped) when loading core dump (armhf on arm64)
https://bugs.llvm.org/show_bug.cgi?id=37986 Bug ID: 37986 Summary: Segmentation fault (core dumped) when loading core dump (armhf on arm64) Product: lldb Version: 3.9 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: anthony.ab...@gmail.com CC: llvm-b...@lists.llvm.org I get a Segmentation fault (core dumped) error when loading a core dump for a program that was hung. I created the core dump using gcore The process is an armhf (32bit) running on arm64 Easily repeatable, and I have the core dump from lldb if that will help. Some notes - OS: armbian kernel: 4.14.21-sunxi64 (custom) command: lldb-3.9 -c zcore.dump.32684 /path/to/binary actual output: (lldb) target create "/path/to/binary" --core "zcore.dump.32684" Segmentation fault (core dumped) process is a .Net core 2.1 application which according to docs requires lldb 3.9 for debugging I can think of a few things going wrong here (given the types of problems i have had in the past getting everything else working) 1. kernel / os missing features? 2. lldb running 64bit version instead of 32bit (does it even matter?) 3. user error? 4. lldb bug? Any suggestions, or help is appreciated! -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb-mi doesn't propagate host environment variables
Hello!
lldb-mi doesn't propagate host environment variables while lldb does it:
$ cat env.c
#include
#include
int main()
{
printf("VAR = %s\n", getenv("VAR"));
return 0;
}
$ gcc env.c -o env
$ /home/kbaladurin/Downloads/llvm-x64-7.0/bin/lldb -v
lldb version 7.0.0
$ VAR=1 /home/kbaladurin/Downloads/llvm-x64-7.0/bin/lldb env
(lldb) target create "env"
Current executable set to 'env' (x86_64).
(lldb) r
Process 13139 launched: '/home/kbaladurin/Desktop/tests/env' (x86_64)
VAR = 1
Process 13139 exited with status = 0 (0x)
(lldb) ^D
$ VAR=1 /home/kbaladurin/Downloads/llvm-x64-7.0/bin/lldb-mi
(gdb)
-file-exec-and-symbols env
^done
(gdb)
=library-loaded,id="/home/kbaladurin/Desktop/tests/env",target-name="/home/kbaladurin/Desktop/tests/env",host-name="/home/kbaladurin/Desktop/tests/env",symbols-loaded="0",loaded_addr="-",size="0"
-exec-run
^running
=thread-group-started,id="i1",pid="13176"
(gdb)
=thread-created,id="1",group-id="i1"
=thread-selected,id="1"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/ld-2.23.so",target-name="/lib/x86_64-linux-gnu/ld-2.23.so",host-name="/lib/x86_64-linux-gnu/ld-2.23.so",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/ld-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="[vdso]",target-name="[vdso]",host-name="[vdso]",symbols-loaded="1",symbols-path="",loaded_addr="0x77ffa000",size="0"
(gdb)
=library-loaded,id="/home/kbaladurin/Desktop/tests/env",target-name="/home/kbaladurin/Desktop/tests/env",host-name="/home/kbaladurin/Desktop/tests/env",symbols-loaded="0",loaded_addr="-",size="0"
(gdb)
*running,thread-id="all"
(gdb)
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so",loaded_addr="-",size="0"
(gdb)
=library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="1",symbols-path="/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so",loaded_addr="-",size="0"
@"VAR = (null)\r\n"
(gdb)
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
(gdb)
Is it expected behavior?
Thank you!
BR,
Konstantin Baladurin
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py
I did a search for the "HLOp" symbol and it turned out it is only used by
the "LLVMSupport.so" lib.
So, this did not help, thus I dug deeper and examined the test binary
further.
`_exit` is called during the initialization of the static HLOp object
(dlopen() calls call_init() which executes the static initialization of the
object).
But for some strange reason it turned out the init function
(llvm::cl::OptionCategory::registerCategory()) is called
from /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1 .
So then I used strace to find out that first "libLLVMSupport.so.7" is
loaded by the dynamic loader and then later the "
/usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1".
Both have the `registerCategory()` function called during the load of the
lib and the second call causes the error.
The sequence of the `open` syscalls shows that my local python installation
brings in my local lldb lib which in turn loads the local libLLVM lib. And
this is the problem. Below attached the detailed log of the open calls.
One solution is to uninstall my local lldb or use a different python, or
use a virtual env for python - which does not contain any lldb modules -
when running these tests.
Perhaps, somehow we could discover with cmake that the local python install
contains lldb and issue a diagnostic in that case, but this seems quite
complicated.
Thanks,
Gabor
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/tls/x86_64/libgtest_main.so.7",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/tls/libgtest_main.so.7",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/x86_64/libgtest_main.so.7",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libgtest_main.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libgtest.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libpython2.7.so.1.0",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0", O_RDONLY|O_CLOEXEC) =
3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDemangle.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangFrontend.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMExecutionEngine.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMCore.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMRuntimeDyld.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangCodeGen.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangDriver.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangEdit.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangParse.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangRewrite.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangSema.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMMCJIT.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangBasic.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDebugInfoDWARF.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangLex.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDebugInfoPDB.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMSupport.so.7",
O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libpthread.so.0",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libdl.so.2",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libedit.so.2",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libedit.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libncurses.so.5",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libncurses.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libtinfo.so.5",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC)
Re: [lldb-dev] Linux: Failing lldb unit tests and TestLinuxCore.py
So, on Ubuntu "sudo apt-get remove python-lldb-4.0" solved this issue.
Thanks again for the guidance.
Cheers,
Gabor
On Fri, Jun 29, 2018 at 4:10 PM Gábor Márton wrote:
> I did a search for the "HLOp" symbol and it turned out it is only used by
> the "LLVMSupport.so" lib.
> So, this did not help, thus I dug deeper and examined the test binary
> further.
>
> `_exit` is called during the initialization of the static HLOp object
> (dlopen() calls call_init() which executes the static initialization of the
> object).
> But for some strange reason it turned out the init function
> (llvm::cl::OptionCategory::registerCategory()) is called
> from /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1 .
> So then I used strace to find out that first "libLLVMSupport.so.7" is
> loaded by the dynamic loader and then later the "
> /usr/lib/x86_64-linux-gnu/libLLVM-4.0.so.1".
> Both have the `registerCategory()` function called during the load of the
> lib and the second call causes the error.
> The sequence of the `open` syscalls shows that my local python
> installation brings in my local lldb lib which in turn loads the local
> libLLVM lib. And this is the problem. Below attached the detailed log of
> the open calls.
> One solution is to uninstall my local lldb or use a different python, or
> use a virtual env for python - which does not contain any lldb modules -
> when running these tests.
> Perhaps, somehow we could discover with cmake that the local python
> install contains lldb and issue a diagnostic in that case, but this seems
> quite complicated.
>
> Thanks,
> Gabor
>
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/tls/x86_64/libgtest_main.so.7",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/tls/libgtest_main.so.7",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/x86_64/libgtest_main.so.7",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libgtest_main.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libgtest.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libpython2.7.so.1.0",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> open("/usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0", O_RDONLY|O_CLOEXEC)
> = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDemangle.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangFrontend.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMExecutionEngine.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMCore.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMRuntimeDyld.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangCodeGen.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangDriver.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangEdit.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangParse.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangRewrite.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangSema.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMMCJIT.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangBasic.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDebugInfoDWARF.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libclangLex.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMDebugInfoPDB.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libLLVMSupport.so.7",
> O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libpthread.so.0",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libdl.so.2",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/lib/libedit.so.2",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> open("/usr/lib/x86_64-linux-gnu/libedit.so.2", O_RDONLY|O_CLOEXEC) = 3
> open("/home/egbomrt/WORK/llvm3/build/release_assert/
[lldb-dev] Issues (resolved) with running lldb test-suite on Ubuntu 18.04 LTS
Just a heads up, I had run into some issues running make check-lldb. I found the solution to be setting: PYTHON_INCLUDE_DIRS=/usr/include/python2.7 PYTHON_LIBRARIES=/usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7.so prior to running cmake. Of course python2.7-dev needs to be installed prior. I don't know if this can be done a better way through pyenv or something like that, but I just thought I'd put that out there. PL ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Issues (resolved) with running lldb test-suite on Ubuntu 18.04 LTS
Hi Puyan, > On Jun 29, 2018, at 7:30 PM, Puyan Lotfi via lldb-dev > wrote: > > Just a heads up, I had run into some issues running make check-lldb. I found > the solution to be setting: > > PYTHON_INCLUDE_DIRS=/usr/include/python2.7 > PYTHON_LIBRARIES=/usr/lib/python2.7/config-x86_64-linux-gnu/libpython2.7.so > > prior to running cmake. Of course python2.7-dev needs to be installed prior. > > I don’t know if this can be done a better way through pyenv or something like > that, but I just thought I'd put that out there. We’ve had similar issues with Python on Darwin. One potential cause of problems is linking against a different version of Python than the interpreter. If you install Python trough python.org or Homebrew, CMake finds that version for the interpreter, but the system one for libpython2.7.dylib. -- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.10") <- System Python -- Found PythonInterp: /usr/local/bin/python2.7 (found version "2.7.15") <- Homebrew Python I’ve been told that as of version 3.12 of CMake, there will be a new interface to FindPython that will ensure consistently and differentiate between Python 2 and Python 3 (which I presume is your issue here). I don’t know if CMake supports doing different things depending on the version, but hopefully this will be resolved in the future. In the meantime (on macOS) I just unlinked the Python interpreter from /usr/local/bin. > > PL > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Issues (resolved) with running lldb test-suite on Ubuntu 18.04 LTS
Oh interesting, so this is an issue with cmake not just ubuntu. Thanks for the heads up; I'll remember that when im on Darwin next. PL On Fri, Jun 29, 2018 at 12:07 PM Jonas Devlieghere wrote: > Hi Puyan, > > > On Jun 29, 2018, at 7:30 PM, Puyan Lotfi via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Just a heads up, I had run into some issues running make check-lldb. I > found the solution to be setting: > > > > PYTHON_INCLUDE_DIRS=/usr/include/python2.7 > > PYTHON_LIBRARIES=/usr/lib/python2.7/config-x86_64-linux-gnu/ > libpython2.7.so > > > > prior to running cmake. Of course python2.7-dev needs to be installed > prior. > > > > I don’t know if this can be done a better way through pyenv or something > like that, but I just thought I'd put that out there. > > We’ve had similar issues with Python on Darwin. One potential cause of > problems is linking against a different version of Python than the > interpreter. If you install Python trough python.org or Homebrew, CMake > finds that version for the interpreter, but the system one for > libpython2.7.dylib. > > -- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.10") > <- System Python > -- Found PythonInterp: /usr/local/bin/python2.7 (found version "2.7.15") > <- Homebrew Python > > I’ve been told that as of version 3.12 of CMake, there will be a new > interface to FindPython that will ensure consistently and differentiate > between Python 2 and Python 3 (which I presume is your issue here). I don’t > know if CMake supports doing different things depending on the version, but > hopefully this will be resolved in the future. In the meantime (on macOS) I > just unlinked the Python interpreter from /usr/local/bin. > > > > > PL > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 37995] New: LLDB only supports GPR registers on Windows
https://bugs.llvm.org/show_bug.cgi?id=37995 Bug ID: 37995 Summary: LLDB only supports GPR registers on Windows Product: lldb Version: 6.0 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: sti...@microsoft.com CC: llvm-b...@lists.llvm.org Only GPR registers are supported in LLDB on Windows. There is no support for floating point registers. -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
