[lldb-dev] LLDB on Linux

[Greg Clayton]

On Jul 19, 2012, at 1:32 PM, Konstantin Tokarev wrote:

> 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. 
> 
> [1] http://lldb.llvm.org/build.html
> 
> -- 
> Regards,
> Konstantin
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev