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