[lldb-dev] Problems running the lldb tests on Fedora Core 20 - 64bit (email originally titled "Add kalimba as a platform.")
Matthew Gardiner
mg11 at csr.com
Mon Jul 21 02:34:06 PDT 2014
Hi Todd,
Thanks for taking the time to come up with these tips. First off my
distro is Fedora Core 20 64-bit. So to further my investigation I blew
away all the sources, and did svn co llvm, (lldb clang into llvm/tools),
made the sibling build dir, then did:
~/src/p4play/build
$ ../llvm/configure --enable-targets=x86_64 --enable-shared
--enable-cxx11 --prefix=`pwd`/../install && make -j 8
After the successful build I do ldd. Basically lld finds all
dependencies for liblldb.so...
~/src/p4play/build/Debug+Asserts/lib
$ ldd liblldb.so
linux-vdso.so.1 => (0x00007fffa61fe000)
libLLVM-3.5svn.so =>
/home/mg11/src/p4play/build/Debug+Asserts/lib/./libLLVM-3.5svn.so
(0x00007f2e53405000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2e531cc000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2e52fc8000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f2e52dc5000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f2e529fe000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2e527f6000)
libedit.so.0 => /lib64/libedit.so.0 (0x00007f2e525ba000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f2e52392000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f2e52168000)
libpanel.so.5 => /lib64/libpanel.so.5 (0x00007f2e51f64000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2e51d4d000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2e51a46000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2e5173e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2e51527000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2e51168000)
/lib64/ld-linux-x86-64.so.2 (0x0000003675a00000)
However, regarding python loading the lldb bindings I see my
build/Debug+Asserts has a lib and a lib64 folder.
~/src/p4play/build/Debug+Asserts
$ ls
bin lib lib64
If I try to import lldb when I have "lib" as my PYTHONPATH i.e.
~/src/main/build/Debug+Asserts/lib
$ PYTHONPATH=`pwd`/python2.7/site-packages/ python
>>> import lldb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named lldb
>>>
This is not surprising, since
~/src/main/build/Debug+Asserts/lib/python2.7/site-packages/ only
contains readline.so.
So I cd to lib64. This looks more promising since there is a lldb folder
below site-packages. So now I do "import lldb" with "lib64" instead:
~/src/main/build/Debug+Asserts/lib64
$ PYTHONPATH=`pwd`/lib64/python2.7/site-packages/ python
Python 2.7.5 (default, Feb 19 2014, 13:47:28)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lldb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/home/mg11/src/main/build/Debug+Asserts/lib64/python2.7/site-packages/lldb/__init__.py",
line 52, in <module>
_lldb = swig_import_helper()
File
"/home/mg11/src/main/build/Debug+Asserts/lib64/python2.7/site-packages/lldb/__init__.py",
line 44, in swig_import_helper
import _lldb
ImportError: No module named _lldb
>>>
So cd to
~/src/p4play/build/Debug+Asserts/lib64/python2.7/site-packages/lldb, and
list:
~/src/p4play/build/Debug+Asserts/lib64/python2.7/site-packages/lldb
$ ls -l
total 1196
-rw-rw-r-- 1 mg11 mg11 3905 Jul 21 08:25 embedded_interpreter.py
drwxrwxr-x 3 mg11 mg11 4096 Jul 21 08:25 formatters
-rw-rw-r-- 1 mg11 mg11 495675 Jul 21 08:25 __init__.py
-rw-rw-r-- 1 mg11 mg11 708200 Jul 21 09:09 __init__.pyc
lrwxrwxrwx 1 mg11 mg11 19 Jul 21 08:25 _lldb.so ->
../../../liblldb.so !BROKEN SYMLINK!
drwxrwxr-x 2 mg11 mg11 4096 Jul 21 08:25 runtime
drwxrwxr-x 2 mg11 mg11 4096 Jul 21 08:25 utils
_lldb.so is broken above as the link above assumes liblldb.so is just 3
dirs back. However, it isn't - because it's not in lib64, *it's in lib*.
So it looks like things are getting a bit mashed up due to 32-bit/64-bit
directory issues. If I copy the .so files from lib to lib64, then it
fixes my broken sym-link issue. And I progress a little further.
~/src/p4play/build/Debug+Asserts/lib64
$ PYTHONPATH=`pwd`/python2.7/site-packages python
Python 2.7.5 (default, Feb 19 2014, 13:47:28)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lldb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/home/mg11/src/p4play/build/Debug+Asserts/lib64/python2.7/site-packages/lldb/__init__.py",
line 52, in <module>
_lldb = swig_import_helper()
File
"/home/mg11/src/p4play/build/Debug+Asserts/lib64/python2.7/site-packages/lldb/__init__.py",
line 48, in swig_import_helper
_mod = imp.load_module('_lldb', fp, pathname, description)
ImportError: libLLVM-3.5svn.so: cannot open shared object file: No such
file or directory
>>>
So now I push the location of these .sos into my environment with
LD_LIBRARY_PATH. Finally lldb imports!
~/src/p4play/build/Debug+Asserts/lib64
$ LD_LIBRARY_PATH=. PYTHONPATH=`pwd`/python2.7/site-packages python
Python 2.7.5 (default, Feb 19 2014, 13:47:28)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lldb
>>> dir(lldb)
['INT32_MAX', 'LLDB_ARCH_DEFAULT',
... lots more ...
>>>
So, I think the crux of the problem I'm seeing here is that on a 64-bit
linux build (using autoconf/make) we get the binaries distributed around
the lib and lib64 sub-folders without adequate coordination with the
test tools. I'll retry now with cmake/ninja and see if my experience
differs.
Matt
Todd Fiala wrote:
>
> Hey Matt,
>
> (Adding back the list since these are general troubleshooting tips for
> getting tests running).
>
> Sorry you’re having so much trouble with this!
>
> Ok so a few things to troubleshoot:
>
> Regardless of the build system used, go to the build output’s lib dir.
> Do this command:
> ldd liblldb.so
>
> That will spit out all the shared libraries that your liblldb.so is
> trying to link against. The python message your seeing will happen if
> python can’t find the lldb module (as the message suggests and you
> were tracing down), /or/ if it can find it but fails to load it (which
> is often the case - something cannot be found when the liblldb.so
> tries to load as a consequence of the lldb python module trying to load).
>
> You should see something that looks roughly like this:
>
> |tfiala at tfiala2:/mnt/ssd/work/macosx.sync/mbp-svn/build-debug/lib$ ldd liblldb.so
> linux-vdso.so.1 => (0x00007fffe9dfe000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6357e71000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6357b6b000)
> libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007f635793a000)
> libpanel.so.5 => /usr/lib/x86_64-linux-gnu/libpanel.so.5 (0x00007f6357736000)
> libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007f6357513000)
> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f63572e9000)
> libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f6356d82000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6356b7a000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6356975000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6356757000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f635653e000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6356327000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6355f61000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f635d584000)
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f6355d5d000)
> tfiala at tfiala2:/mnt/ssd/work/macosx.sync/mbp-svn/build-debug/lib$site-packages
> |
>
> The left side shows the short name that the .so is referencing. The
> right side shows what the loader actually mapped it to with the
> current environment. If there is a problem loading liblldb.so, this
> will show as (I think) question marks on the right side indicating
> that the shared library linkage was not found. Let me know if you see
> something like that.
>
> If you get past this part and you don’t see any issues, the next thing
> to try is:
> PYTHONPATH=/path/to/your/lldb/lib/python2.7/site-packages python
> Then do an ‘import lldb’, then a ‘dir (lldb)’, like so:
>
> |tfiala at tfiala2:/mnt/ssd/work/macosx.sync/mbp-svn/build-debug/lib$ PYTHONPATH=`pwd`/python2.7/site-packages python
> Python 2.7.6 (default, Mar 22 2014, 22:59:56)
> [GCC 4.8.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import lldb
> >>> dir(lldb)
> ['INT32_MAX', 'LLDB_ARCH_DEFAULT', 'LLDB_ARCH_DEFAULT_32BIT', 'LLDB_ARCH_DEFAULT_64BIT', 'LLDB_DEFAULT_BREAK_SIZE', 'LLDB_DEFAULT_SHELL', 'LLDB_GENERIC_ERROR', 'LLDB_INVALID_ADDRESS', 'LLDB_INVALID_BREAK_ID', 'LLDB_INVALID_CPUTYPE', 'LLDB_INVALID_FRAME_ID', 'LLDB_INVALID_IMAGE_TOKEN', 'LLDB_INVALID_INDEX32', 'LLDB_INVALID_IVAR_OFFSET', 'LLDB_INVALID_LINE_NUMBER', 'LLDB_INVALID_MODULE_VERSION', 'LLDB_INVALID_OFFSET', 'LLDB_INVALID_PROCESS_ID', 'LLDB_INVALID_QUEUE_ID', 'LLDB_INVALID_REGNUM', 'LLDB_INVALID_SIGNAL_NUMBER', 'LLDB_INVALID_THREAD_ID', 'LLDB_INVALID_UID', 'LLDB_INVALID_WATCH_ID', 'LLDB_MAX_NUM_OPTION_SETS', 'LLDB_OPT_SET_1',
>
> ... (lots of stuff removed)
> |
>
> That will tell you if you can load the lldb module when you specify
> exactly where it should be. If you can do this, the tests basically
> should not have trouble loading lldb. (Obviously somewhere we’ll find
> an issue here). If this does work, then we need to trace why the
> python test runner calls are mixing up the python path. In general you
> don’t need to specify any options to the ninja/make commands to get
> the tests to run from the build dir.
>
> Can you refresh my memory on what Linux distro you’re using and
> whether it’s 64 or 32 bit? (I don’t get over to the 32-bit distros
> much these days).
>
> I hope that gets us closer to finding out what’s up! Keep me posted.
>
> -Todd
>
>
>
>
> On Fri, Jul 18, 2014 at 4:56 AM, Matthew Gardiner <mg11 at csr.com
> <mailto:mg11 at csr.com>> wrote:
>
> Hi Todd,
>
> Well I managed to get cmake and ninja working! I needed (it would
> appear) to download/build/install the latest versions of both from
> source. Then I do:
>
> build $ cmake ../llvm/ -G Ninja -DLLVM_TARGETS_TO_BUILD="X86"
> -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_CXX1Y=ON
> ...
> build $ ninja
> ...
>
> However "ninja check-lldb" still fails to find lldb.py. It is does
> get built, but the path which dotest.py uses to find it is wrong
> on my system. Anyway, I'm going to continue trying to analyse it
> myself for now. I'll probably post a new thread to lldb-dev if I
> continue to struggle.
>
> Anyway, have a good weekend,
> Matt
>
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in
> England and Wales, registered number 4187346, registered office
> Churchill House, Cambridge Business Park, Cowley Road, Cambridge,
> CB4 0WZ, United Kingdom
> More information can be found at www.csr.com <http://www.csr.com>.
> Keep up to date with CSR on our technical blog, www.csr.com/blog
> <http://www.csr.com/blog>, CSR people blog, www.csr.com/people
> <http://www.csr.com/people>, YouTube, www.youtube.com/user/CSRplc
> <http://www.youtube.com/user/CSRplc>, Facebook,
> www.facebook.com/pages/CSR/191038434253534
> <http://www.facebook.com/pages/CSR/191038434253534>, or follow us
> on Twitter at www.twitter.com/CSR_plc
> <http://www.twitter.com/CSR_plc>.
> New for 2014, you can now access the wide range of products
> powered by aptX at www.aptx.com <http://www.aptx.com>.
>
>
>
>
> --
> Todd Fiala | Software Engineer | tfiala at google.com
> <mailto:tfiala at google.com> | 650-943-3180
>
>
>
>
> To report this email as spam click here
> <https://www.mailcontrol.com/sr/ik8jrXaVfBTGX2PQPOmvUj%21GOBh06pKK3+K9eZ%212Dx6F%21Jeeftdx9RBpik88jjuoRisi26jPZSzJaydNu2tBwg==>.
>
More information about the lldb-dev
mailing list