[lldb-dev] [Lldb-commits] [lldb] r213158 - Add kalimba as a platform.

[Todd Fiala]

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$

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> 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. Keep up to date with CSR on
> our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140718/2efb9ade/attachment.html>