[lldb-dev] LLDB on Linux

[Filipe Cabecinhas]

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


On Thursday, July 19, 2012 at 10:26 PM, Greg Clayton wrote:

> 
> 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 (mailto:lldb-dev at cs.uiuc.edu)
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu (mailto:lldb-dev at cs.uiuc.edu)
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev