LLDB on Linux

Hi all,

I've built LLDB on Linux, but it does not work properly: when running "lldb myexecutable" it prints

   Current executable set to './myexecutable' (x86_64).

then uses 100% CPU and nothing happens. It also doesn't respond on Ctrl-C.

To make it starting without exceptions, I had to add Release+Asserts/lib/python to PYTHONPATH (note that documentation [1] advices "Set PYTHONPATH to point to the directory holding lldb.py").

Is Python 2.7 a hard requirement for running LLDB?

[1] http://lldb.llvm.org/build.html

Hi all,

I've built LLDB on Linux, but it does not work properly: when running "lldb myexecutable" it prints

  Current executable set to './myexecutable' (x86_64).

then uses 100% CPU and nothing happens. It also doesn't respond on Ctrl-C.

To make it starting without exceptions, I had to add Release+Asserts/lib/python to PYTHONPATH (note that documentation [1] advices "Set PYTHONPATH to point to the directory holding lldb.py").

It sounds like the following function isn't doing its job on linux in lldb/source/Host/Common/Host.cpp:

bool
Host::GetLLDBPath (PathType path_type, FileSpec &file_spec);

This functions helps find things that are distrubuted with LLDB. The path type returned is specified using an enumeration "lldb_private::PathType". Details are in the enumerations from lldb-private-enumerations.h:

//----------------------------------------------------------------------
// Used in conjunction with Host::GetLLDBPath () to find files that
// are related to
//----------------------------------------------------------------------
typedef enum PathType
{
    ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists
    ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc)
    ePathTypeHeaderDir, // Find LLDB header file directory
    ePathTypePythonDir, // Find Python modules (PYTHONPATH) directory
    ePathTypeLLDBSystemPlugins, // System plug-ins directory
    ePathTypeLLDBUserPlugins // User plug-ins directory
} PathType;

There is a case statement for the "ePathTypePythonDir" which isn't doing the right thing for linux:

    case ePathTypePythonDir:
        {
            // TODO: Anyone know how we can determine this for linux? Other systems?
            // For linux we are currently assuming the location of the lldb
            // binary that contains this function is the directory that will
            // contain lldb.so, lldb.py and embedded_interpreter.py...

            static ConstString g_lldb_python_dir;
            if (!g_lldb_python_dir)
            {
                FileSpec lldb_file_spec;
                if (GetLLDBPath (ePathTypeLLDBShlibDir, lldb_file_spec))
                {
                    char raw_path[PATH_MAX];
                    char resolved_path[PATH_MAX];
                    lldb_file_spec.GetPath(raw_path, sizeof(raw_path));

#if defined (__APPLE__)
                    char *framework_pos = ::strstr (raw_path, "LLDB.framework");
                    if (framework_pos)
                    {
                        framework_pos += strlen("LLDB.framework");
                        ::strncpy (framework_pos, "/Resources/Python", PATH_MAX - (framework_pos - raw_path));
                    }
#endif
                    FileSpec::Resolve (raw_path, resolved_path, sizeof(resolved_path));
                    g_lldb_python_dir.SetCString(resolved_path);
                }
            }
            file_spec.GetDirectory() = g_lldb_python_dir;
            return file_spec.GetDirectory();
        }
        break;

On MacOSX we have our lldb.py file in our shared library, so we use the GetLLDBPath() function with "ePathTypeLLDBShlibDir" to locate the shared library (which is "$(BUILD_DIR)/LLDB.framework/Contents/MacOS/LLDB"), then we play with this path to remove the come up with "$(BUILD_DIR)/LLDB.framework/Resources/Python".

On Linux, it is trying to get "ePathTypeLLDBShlibDir", or the directory in which the lldb.so shared library file exists, and it is assuming that the lldb.py file is in this directory. I am not sure how things on linux are going to be installed eventually, but it will differ between the different configurations. The three configurations we support via preprocessor macros are currently:

#if defined (LLDB_CONFIGURATION_BUILD_AND_INTEGRATION)
  // The LLDB built for distrubution
#else
  // Debug version of LLDB used for building and debugging LLDB without installing it
#endif

So for linux you might need to do some extra logic here. If you fix this function, it should work.

Is Python 2.7 a hard requirement for running LLDB?

Most testing happens with 2.7 since this is the default on MacOSX.

Hi all,

From what I can tell, the only problem with running on python 2.6 instead of 2.7 is that there is no decorator @functools.total_ordering, for the obj-C formatters.

You won't have an error, only a warning. I haven't properly tested that formatter, to make sure that removing the decorator has no impact, but I've been doing just that: deleting that line. For what I'm doing there is no problem (and on linux you won't have many problems, I suppose).

Regards,

  Filipe

That Python path bug is fixed. But I'll check the other paths that can be requested using Host::GetLLDBPath and try to get them all correct using only relative paths (which seems the best choice. That should work for in-tree and installed builds using makefiles.

But Host.cpp still has some MACOSX ifdefs on Host::GetLLDBPath. I suppose that code has bit-rotted, since Host.mm implements that method. I just wanted to double-check with you before removing them.

Regards,

  Filipe