[lldb-dev] [Bug 31192] New: Unwinding of noreturn functions fails if the function is the last function in a section

2016-11-28 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=31192

Bug ID: 31192
   Summary: Unwinding of noreturn functions fails if the function
is the last function in a section
   Product: lldb
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The reason for that is that the caller PC can end up outside the bounds of any
module. We have special code which handles the case where the PC lands outside
the function bounds (but still within the correct module). However that fails
when the PC actually ends up outside any module.

Currently, this breaks TestNoreturnUnwind on android x86_64, but I am pretty
sure it can be reproduced on any target.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Ted Woodward via lldb-dev 
Windows has no concept of a default python installation, and I can’t be sure 
what version of python my users have, if any, so I need to solve 2 problems:

1)  Where is python when I’m building?

2)  Where is python when I’m running?

 

To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my 
python installation (on our buildbots, c:/python351).

 

#2 only needs to be solved if the machine you’re running on doesn’t have the 
same python installation, in PYTHON_HOME above. To do that, I’ve added code to 
set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro down to 
InitializePythonHome in 
source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and call 
Py_SetPythonHome with it. My installations have the python dll and python 
library directory. We put the library in /lib/python35 and the dll in 
/bin.

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Wednesday, November 23, 2016 12:40 PM
To: Vadim Chugunov 
Cc: Reid Kleckner ; Hans Wennborg ; LLDB 
; Ted Woodward 
Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

 

I believe the way to fix this is going to be building LLDB for the installer 
with LLDB_RELOCATABLE_PYTHON=1 at CMake time

 

+Ted, since I believe he is one of the few people currently using this flag.

On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

This is still broken in the October snapshot.   Do you know which script is 
used to build the Windows installer?

 

On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

I think it is a problem with the way we built lldb.  I will look into what 
additional steps we need to take when making the prebuilt binary so that it 
works next time.

 

On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

Nope, that didn't help.

 

On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

I may know what this is.  Can you try setting PYTHONPATH though to point to 
your Python 3.5 installation though and see if it fixes it?  (I don't think it 
will, but let's try anyway)

 

On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the 
'site-packages' directory does not exist.  Nor do I see '_lldb.pyd' anywhere 
else.  

'script import lldb' also fails, of course.

 

On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner mailto:ztur...@google.com> > wrote:

He said he did, so I don't know.  Vadim, can you elaborate?  When you run `lldb 
-P` from the command line, what do you see?

 

On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

I imagine that Hans doesn't have Python 3 installed on his system, so LLDB 
didn't autoconfigure with Python support.

 

On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev 
mailto:lldb-dev@lists.llvm.org> > wrote:

> Does the 4.0 binary not work for you? It is the first release that contains 
> prebuilt lldb binary. 

 

Looks like the Python API is not included though.   Do you know why it was left 
out?

 


___
lldb-dev mailing list
lldb-dev@lists.llvm.org  
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org  
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

 

 

 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Zachary Turner via lldb-dev 
So it sounds like you're saying that in order for Python support to work as
part of an LLDB shipped in the installer, we need to do set 3 variables at
CMake time.

1) -DLLDB_RELOCATABLE_PYTHON=TRUE
2) -DPYTHON_HOME = 
3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE

Now because of #3, the lldb shipped in the installer will use the
PYTHONHOME system environment variable to locate python, which must point
to a valid Python 3.5 installation.  Is this correct?

On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward 
wrote:

> Windows has no concept of a default python installation, and I can’t be
> sure what version of python my users have, if any, so I need to solve 2
> problems:
>
> 1)  Where is python when I’m building?
>
> 2)  Where is python when I’m running?
>
>
>
> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my
> python installation (on our buildbots, c:/python351).
>
>
>
> #2 only needs to be solved if the machine you’re running on doesn’t have
> the same python installation, in PYTHON_HOME above. To do that, I’ve added
> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro
> down to InitializePythonHome in
> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
> call Py_SetPythonHome with it. My installations have the python dll and
> python library directory. We put the library in /lib/python35 and
> the dll in /bin.
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Wednesday, November 23, 2016 12:40 PM
> *To:* Vadim Chugunov 
> *Cc:* Reid Kleckner ; Hans Wennborg ;
> LLDB ; Ted Woodward 
> *Subject:* Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>
>
>
> I believe the way to fix this is going to be building LLDB for the
> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>
>
>
> +Ted, since I believe he is one of the few people currently using this
> flag.
>
> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov  wrote:
>
> This is still broken in the October snapshot.   Do you know which script
> is used to build the Windows installer?
>
>
>
> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
> wrote:
>
> I think it is a problem with the way we built lldb.  I will look into what
> additional steps we need to take when making the prebuilt binary so that it
> works next time.
>
>
>
> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov  wrote:
>
> Nope, that didn't help.
>
>
>
> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
> wrote:
>
> I may know what this is.  Can you try setting PYTHONPATH though to point
> to your Python 3.5 installation though and see if it fixes it?  (I don't
> think it will, but let's try anyway)
>
>
>
> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov  wrote:
>
> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
> anywhere else.
>
> 'script import lldb' also fails, of course.
>
>
>
> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
> wrote:
>
> He said he did, so I don't know.  Vadim, can you elaborate?  When you run
> `lldb -P` from the command line, what do you see?
>
>
>
> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I imagine that Hans doesn't have Python 3 installed on his system, so LLDB
> didn't autoconfigure with Python support.
>
>
>
> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> > Does the 4.0 binary not work for you? It is the first release that
> contains prebuilt lldb binary.
>
>
>
> Looks like the Python API is not included though.   Do you know why it was
> left out?
>
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
>
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Hans Wennborg via lldb-dev 
The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.

I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.

On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner  wrote:
> So it sounds like you're saying that in order for Python support to work as
> part of an LLDB shipped in the installer, we need to do set 3 variables at
> CMake time.
>
> 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> 2) -DPYTHON_HOME = 
> 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>
> Now because of #3, the lldb shipped in the installer will use the PYTHONHOME
> system environment variable to locate python, which must point to a valid
> Python 3.5 installation.  Is this correct?
>
> On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward 
> wrote:
>>
>> Windows has no concept of a default python installation, and I can’t be
>> sure what version of python my users have, if any, so I need to solve 2
>> problems:
>>
>> 1)  Where is python when I’m building?
>>
>> 2)  Where is python when I’m running?
>>
>>
>>
>> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my
>> python installation (on our buildbots, c:/python351).
>>
>>
>>
>> #2 only needs to be solved if the machine you’re running on doesn’t have
>> the same python installation, in PYTHON_HOME above. To do that, I’ve added
>> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro
>> down to InitializePythonHome in
>> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
>> call Py_SetPythonHome with it. My installations have the python dll and
>> python library directory. We put the library in /lib/python35 and
>> the dll in /bin.
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com]
>> Sent: Wednesday, November 23, 2016 12:40 PM
>> To: Vadim Chugunov 
>> Cc: Reid Kleckner ; Hans Wennborg ;
>> LLDB ; Ted Woodward 
>> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>
>>
>>
>> I believe the way to fix this is going to be building LLDB for the
>> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>
>>
>>
>> +Ted, since I believe he is one of the few people currently using this
>> flag.
>>
>> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov  wrote:
>>
>> This is still broken in the October snapshot.   Do you know which script
>> is used to build the Windows installer?
>>
>>
>>
>> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>> wrote:
>>
>> I think it is a problem with the way we built lldb.  I will look into what
>> additional steps we need to take when making the prebuilt binary so that it
>> works next time.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov  wrote:
>>
>> Nope, that didn't help.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>> wrote:
>>
>> I may know what this is.  Can you try setting PYTHONPATH though to point
>> to your Python 3.5 installation though and see if it fixes it?  (I don't
>> think it will, but let's try anyway)
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov  wrote:
>>
>> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd' anywhere
>> else.
>>
>> 'script import lldb' also fails, of course.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> wrote:
>>
>> He said he did, so I don't know.  Vadim, can you elaborate?  When you run
>> `lldb -P` from the command line, what do you see?
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev
>>  wrote:
>>
>> I imagine that Hans doesn't have Python 3 installed on his system, so LLDB
>> didn't autoconfigure with Python support.
>>
>>
>>
>> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev
>>  wrote:
>>
>> > Does the 4.0 binary not work for you? It is the first release that
>> > contains prebuilt lldb binary.
>>
>>
>>
>> Looks like the Python API is not included though.   Do you know why it was
>> left out?
>>
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Vadim Chugunov via lldb-dev 
Please correct me if I'm wrong, but isn't the issue here that LLDB's Python
support files don't get packaged into the Windows installer?   Does
packaging them somehow depend on knowing what the Python installation path
is?

On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  wrote:

> The snapshots are built with the script in
> utils/release/build_llvm_package.bat. It's currently passing
> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>
> I was planning on trying to build a new snapshot today and can add
> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>
> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
> wrote:
> > So it sounds like you're saying that in order for Python support to work
> as
> > part of an LLDB shipped in the installer, we need to do set 3 variables
> at
> > CMake time.
> >
> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> > 2) -DPYTHON_HOME = 
> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
> >
> > Now because of #3, the lldb shipped in the installer will use the
> PYTHONHOME
> > system environment variable to locate python, which must point to a valid
> > Python 3.5 installation.  Is this correct?
> >
> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward <
> ted.woodw...@codeaurora.org>
> > wrote:
> >>
> >> Windows has no concept of a default python installation, and I can’t be
> >> sure what version of python my users have, if any, so I need to solve 2
> >> problems:
> >>
> >> 1)  Where is python when I’m building?
> >>
> >> 2)  Where is python when I’m running?
> >>
> >>
> >>
> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
> my
> >> python installation (on our buildbots, c:/python351).
> >>
> >>
> >>
> >> #2 only needs to be solved if the machine you’re running on doesn’t have
> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
> added
> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
> macro
> >> down to InitializePythonHome in
> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp,
> and
> >> call Py_SetPythonHome with it. My installations have the python dll and
> >> python library directory. We put the library in /lib/python35
> and
> >> the dll in /bin.
> >>
> >> --
> >>
> >> Qualcomm Innovation Center, Inc.
> >>
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> >> Linux Foundation Collaborative Project
> >>
> >>
> >>
> >> From: Zachary Turner [mailto:ztur...@google.com]
> >> Sent: Wednesday, November 23, 2016 12:40 PM
> >> To: Vadim Chugunov 
> >> Cc: Reid Kleckner ; Hans Wennborg ;
> >> LLDB ; Ted Woodward <
> ted.woodw...@codeaurora.org>
> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
> >>
> >>
> >>
> >> I believe the way to fix this is going to be building LLDB for the
> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
> >>
> >>
> >>
> >> +Ted, since I believe he is one of the few people currently using this
> >> flag.
> >>
> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
> wrote:
> >>
> >> This is still broken in the October snapshot.   Do you know which script
> >> is used to build the Windows installer?
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
> >> wrote:
> >>
> >> I think it is a problem with the way we built lldb.  I will look into
> what
> >> additional steps we need to take when making the prebuilt binary so
> that it
> >> works next time.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
> wrote:
> >>
> >> Nope, that didn't help.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
> >> wrote:
> >>
> >> I may know what this is.  Can you try setting PYTHONPATH though to point
> >> to your Python 3.5 installation though and see if it fixes it?  (I don't
> >> think it will, but let's try anyway)
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
> wrote:
> >>
> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
> >> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
> anywhere
> >> else.
> >>
> >> 'script import lldb' also fails, of course.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
> >> wrote:
> >>
> >> He said he did, so I don't know.  Vadim, can you elaborate?  When you
> run
> >> `lldb -P` from the command line, what do you see?
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev
> >>  wrote:
> >>
> >> I imagine that Hans doesn't have Python 3 installed on his system, so
> LLDB
> >> didn't autoconfigure with Python support.
> >>
> >>
> >>
> >> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev
> >>  wrote:
> >>
> >> > Does the 4.0 binary not work for you? It is the first release that
> >> > contains prebuilt lldb binary.
> >>
> >>
> >>
> >> Looks like the Python API is not included though.   Do you know why it
> was
> >> left out?
> >>
> >>
> >>
> >>
> >> ___
> >> lldb-dev mailing list
> >> lldb-d

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Zachary Turner via lldb-dev 
I overlooked that part of it, but yes that is another separate issue.
 (BTW, _lldb.pyd is simply a symlink to liblldb.dll).

In any case, yea I think the entire lib/site-packages folder needs to be
included.

On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov  wrote:

> Please correct me if I'm wrong, but isn't the issue here that LLDB's
> Python support files don't get packaged into the Windows installer?   Does
> packaging them somehow depend on knowing what the Python installation path
> is?
>
> On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  wrote:
>
> The snapshots are built with the script in
> utils/release/build_llvm_package.bat. It's currently passing
> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>
> I was planning on trying to build a new snapshot today and can add
> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>
> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
> wrote:
> > So it sounds like you're saying that in order for Python support to work
> as
> > part of an LLDB shipped in the installer, we need to do set 3 variables
> at
> > CMake time.
> >
> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> > 2) -DPYTHON_HOME = 
> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
> >
> > Now because of #3, the lldb shipped in the installer will use the
> PYTHONHOME
> > system environment variable to locate python, which must point to a valid
> > Python 3.5 installation.  Is this correct?
> >
> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward <
> ted.woodw...@codeaurora.org>
> > wrote:
> >>
> >> Windows has no concept of a default python installation, and I can’t be
> >> sure what version of python my users have, if any, so I need to solve 2
> >> problems:
> >>
> >> 1)  Where is python when I’m building?
> >>
> >> 2)  Where is python when I’m running?
> >>
> >>
> >>
> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
> my
> >> python installation (on our buildbots, c:/python351).
> >>
> >>
> >>
> >> #2 only needs to be solved if the machine you’re running on doesn’t have
> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
> added
> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
> macro
> >> down to InitializePythonHome in
> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
> >> call Py_SetPythonHome with it. My installations have the python dll and
> >> python library directory. We put the library in /lib/python35
> and
> >> the dll in /bin.
> >>
> >> --
> >>
> >> Qualcomm Innovation Center, Inc.
> >>
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> >> Linux Foundation Collaborative Project
> >>
> >>
> >>
> >> From: Zachary Turner [mailto:ztur...@google.com]
> >> Sent: Wednesday, November 23, 2016 12:40 PM
> >> To: Vadim Chugunov 
> >> Cc: Reid Kleckner ; Hans Wennborg ;
> >> LLDB ; Ted Woodward <
> ted.woodw...@codeaurora.org>
> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
> >>
> >>
> >>
> >> I believe the way to fix this is going to be building LLDB for the
> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
> >>
> >>
> >>
> >> +Ted, since I believe he is one of the few people currently using this
> >> flag.
> >>
> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
> wrote:
> >>
> >> This is still broken in the October snapshot.   Do you know which script
> >> is used to build the Windows installer?
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
> >> wrote:
> >>
> >> I think it is a problem with the way we built lldb.  I will look into
> what
> >> additional steps we need to take when making the prebuilt binary so
> that it
> >> works next time.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
> wrote:
> >>
> >> Nope, that didn't help.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
> >> wrote:
> >>
> >> I may know what this is.  Can you try setting PYTHONPATH though to point
> >> to your Python 3.5 installation though and see if it fixes it?  (I don't
> >> think it will, but let's try anyway)
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
> wrote:
> >>
> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
> >> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
> anywhere
> >> else.
> >>
> >> 'script import lldb' also fails, of course.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
> >> wrote:
> >>
> >> He said he did, so I don't know.  Vadim, can you elaborate?  When you
> run
> >> `lldb -P` from the command line, what do you see?
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev
> >>  wrote:
> >>
> >> I imagine that Hans doesn't have Python 3 installed on his system, so
> LLDB
> >> didn't autoconfigure with Python support.
> >>
> >>
> >>
> >> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev
> >>  wrote:
> >>
> >> > Does the 4.0 binary not work for you? It is the firs

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Vadim Chugunov via lldb-dev 
At least on my machine, finding Python is not the problem, because Python
installer has added C:\Python35 to the PATH.  (It can also be found in the
Registry at
HKLM\SOFTWARE\Python\PythonCore\3.5-32\InstallPath).


On Mon, Nov 28, 2016 at 10:17 AM, Zachary Turner  wrote:

> I overlooked that part of it, but yes that is another separate issue.
>  (BTW, _lldb.pyd is simply a symlink to liblldb.dll).
>
> In any case, yea I think the entire lib/site-packages folder needs to be
> included.
>
> On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov  wrote:
>
>> Please correct me if I'm wrong, but isn't the issue here that LLDB's
>> Python support files don't get packaged into the Windows installer?   Does
>> packaging them somehow depend on knowing what the Python installation path
>> is?
>>
>> On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg 
>> wrote:
>>
>> The snapshots are built with the script in
>> utils/release/build_llvm_package.bat. It's currently passing
>> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>>
>> I was planning on trying to build a new snapshot today and can add
>> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>>
>> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
>> wrote:
>> > So it sounds like you're saying that in order for Python support to
>> work as
>> > part of an LLDB shipped in the installer, we need to do set 3 variables
>> at
>> > CMake time.
>> >
>> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
>> > 2) -DPYTHON_HOME = 
>> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>> >
>> > Now because of #3, the lldb shipped in the installer will use the
>> PYTHONHOME
>> > system environment variable to locate python, which must point to a
>> valid
>> > Python 3.5 installation.  Is this correct?
>> >
>> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward <
>> ted.woodw...@codeaurora.org>
>> > wrote:
>> >>
>> >> Windows has no concept of a default python installation, and I can’t be
>> >> sure what version of python my users have, if any, so I need to solve 2
>> >> problems:
>> >>
>> >> 1)  Where is python when I’m building?
>> >>
>> >> 2)  Where is python when I’m running?
>> >>
>> >>
>> >>
>> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
>> my
>> >> python installation (on our buildbots, c:/python351).
>> >>
>> >>
>> >>
>> >> #2 only needs to be solved if the machine you’re running on doesn’t
>> have
>> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
>> added
>> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
>> macro
>> >> down to InitializePythonHome in
>> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp,
>> and
>> >> call Py_SetPythonHome with it. My installations have the python dll and
>> >> python library directory. We put the library in /lib/python35
>> and
>> >> the dll in /bin.
>> >>
>> >> --
>> >>
>> >> Qualcomm Innovation Center, Inc.
>> >>
>> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a
>> >> Linux Foundation Collaborative Project
>> >>
>> >>
>> >>
>> >> From: Zachary Turner [mailto:ztur...@google.com]
>> >> Sent: Wednesday, November 23, 2016 12:40 PM
>> >> To: Vadim Chugunov 
>> >> Cc: Reid Kleckner ; Hans Wennborg ;
>> >> LLDB ; Ted Woodward <
>> ted.woodw...@codeaurora.org>
>> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>> >>
>> >>
>> >>
>> >> I believe the way to fix this is going to be building LLDB for the
>> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>> >>
>> >>
>> >>
>> >> +Ted, since I believe he is one of the few people currently using this
>> >> flag.
>> >>
>> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
>> wrote:
>> >>
>> >> This is still broken in the October snapshot.   Do you know which
>> script
>> >> is used to build the Windows installer?
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> I think it is a problem with the way we built lldb.  I will look into
>> what
>> >> additional steps we need to take when making the prebuilt binary so
>> that it
>> >> works next time.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> Nope, that didn't help.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> I may know what this is.  Can you try setting PYTHONPATH though to
>> point
>> >> to your Python 3.5 installation though and see if it fixes it?  (I
>> don't
>> >> think it will, but let's try anyway)
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
>> wrote:
>> >>
>> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> >> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd'
>> anywhere
>> >> else.
>> >>
>> >> 'script import lldb' also fails, of course.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> He said he did, so I don't know.  Vadim, can you elaborate?  W

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Zachary Turner via lldb-dev 
BTW, _lldb.pyd is just a symlink of liblldb.dll.  Perhaps you could try
creating the symlink manually and copying the other files (e.g.
embedded_interpreter.py, six.py, etc) over to see if it works.  If it does,
it would at least confirm that this is everything we need to do to get it
working for you, so that we can have some confidence the next release
doesn't have the problems.

On Mon, Nov 28, 2016 at 10:25 AM Vadim Chugunov  wrote:

> At least on my machine, finding Python is not the problem, because Python
> installer has added C:\Python35 to the PATH.  (It can also be found in the
> Registry at
> HKLM\SOFTWARE\Python\PythonCore\3.5-32\InstallPath).
>
>
> On Mon, Nov 28, 2016 at 10:17 AM, Zachary Turner 
> wrote:
>
> I overlooked that part of it, but yes that is another separate issue.
>  (BTW, _lldb.pyd is simply a symlink to liblldb.dll).
>
> In any case, yea I think the entire lib/site-packages folder needs to be
> included.
>
> On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov  wrote:
>
> Please correct me if I'm wrong, but isn't the issue here that LLDB's
> Python support files don't get packaged into the Windows installer?   Does
> packaging them somehow depend on knowing what the Python installation path
> is?
>
> On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  wrote:
>
> The snapshots are built with the script in
> utils/release/build_llvm_package.bat. It's currently passing
> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>
> I was planning on trying to build a new snapshot today and can add
> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>
> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
> wrote:
> > So it sounds like you're saying that in order for Python support to work
> as
> > part of an LLDB shipped in the installer, we need to do set 3 variables
> at
> > CMake time.
> >
> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> > 2) -DPYTHON_HOME = 
> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
> >
> > Now because of #3, the lldb shipped in the installer will use the
> PYTHONHOME
> > system environment variable to locate python, which must point to a valid
> > Python 3.5 installation.  Is this correct?
> >
> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward <
> ted.woodw...@codeaurora.org>
> > wrote:
> >>
> >> Windows has no concept of a default python installation, and I can’t be
> >> sure what version of python my users have, if any, so I need to solve 2
> >> problems:
> >>
> >> 1)  Where is python when I’m building?
> >>
> >> 2)  Where is python when I’m running?
> >>
> >>
> >>
> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
> my
> >> python installation (on our buildbots, c:/python351).
> >>
> >>
> >>
> >> #2 only needs to be solved if the machine you’re running on doesn’t have
> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
> added
> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
> macro
> >> down to InitializePythonHome in
> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
> >> call Py_SetPythonHome with it. My installations have the python dll and
> >> python library directory. We put the library in /lib/python35
> and
> >> the dll in /bin.
> >>
> >> --
> >>
> >> Qualcomm Innovation Center, Inc.
> >>
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> >> Linux Foundation Collaborative Project
> >>
> >>
> >>
> >> From: Zachary Turner [mailto:ztur...@google.com]
> >> Sent: Wednesday, November 23, 2016 12:40 PM
> >> To: Vadim Chugunov 
> >> Cc: Reid Kleckner ; Hans Wennborg ;
> >> LLDB ; Ted Woodward <
> ted.woodw...@codeaurora.org>
> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
> >>
> >>
> >>
> >> I believe the way to fix this is going to be building LLDB for the
> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
> >>
> >>
> >>
> >> +Ted, since I believe he is one of the few people currently using this
> >> flag.
> >>
> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
> wrote:
> >>
> >> This is still broken in the October snapshot.   Do you know which script
> >> is used to build the Windows installer?
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
> >> wrote:
> >>
> >> I think it is a problem with the way we built lldb.  I will look into
> what
> >> additional steps we need to take when making the prebuilt binary so
> that it
> >> works next time.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
> wrote:
> >>
> >> Nope, that didn't help.
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
> >> wrote:
> >>
> >> I may know what this is.  Can you try setting PYTHONPATH though to point
> >> to your Python 3.5 installation though and see if it fixes it?  (I don't
> >> think it will, but let's try anyway)
> >>
> >>
> >>
> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
> wrote:
> >>
> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
> >> 'site-

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Ted Woodward via lldb-dev 
LLDB_DEFAULT_PYTHONHOME is an internal thing; I haven’t upstreamed it – for a 
while, it conflicted with Zach’s implementation, but I redid it, and everything 
is happy now. If you think it would be useful, I could upstream it. It’s fairly 
small, and plays nice with Zach’s Python stuff.

 

The problem it solves is “where is my python?” on Windows. If you know you’ll 
be running on a system with the same python installation as the build system, 
then you don’t need it. Or if you can tell your users to install the same 
python you built with, in the same location, you’re OK. I can’t do that, so 
instead I ship python, and tell lldb where to find it at build time.

 

We copy over the full site-packages directory that is created by the lldb 
build, and end up with this directory structure:

bin/lldb.exe

bin/liblldb.dll

bin/python35.dll

lib/python35

lib/site-packages

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

 

From: Zachary Turner [mailto:ztur...@google.com] 
Sent: Monday, November 28, 2016 12:17 PM
To: Vadim Chugunov ; Hans Wennborg 
Cc: Ted Woodward ; Reid Kleckner 
; LLDB 
Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

 

I overlooked that part of it, but yes that is another separate issue.  (BTW, 
_lldb.pyd is simply a symlink to liblldb.dll).  

 

In any case, yea I think the entire lib/site-packages folder needs to be 
included.

 

On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov mailto:vadi...@gmail.com> > wrote:

Please correct me if I'm wrong, but isn't the issue here that LLDB's Python 
support files don't get packaged into the Windows installer?   Does packaging 
them somehow depend on knowing what the Python installation path is?

 

On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg mailto:h...@chromium.org> > wrote:

The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.

I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.

On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner mailto:ztur...@google.com> > wrote:
> So it sounds like you're saying that in order for Python support to work as
> part of an LLDB shipped in the installer, we need to do set 3 variables at
> CMake time.
>
> 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> 2) -DPYTHON_HOME = 
> 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>
> Now because of #3, the lldb shipped in the installer will use the PYTHONHOME
> system environment variable to locate python, which must point to a valid
> Python 3.5 installation.  Is this correct?
>
> On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward   >
> wrote:
>>
>> Windows has no concept of a default python installation, and I can’t be
>> sure what version of python my users have, if any, so I need to solve 2
>> problems:
>>
>> 1)  Where is python when I’m building?
>>
>> 2)  Where is python when I’m running?
>>
>>
>>
>> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my
>> python installation (on our buildbots, c:/python351).
>>
>>
>>
>> #2 only needs to be solved if the machine you’re running on doesn’t have
>> the same python installation, in PYTHON_HOME above. To do that, I’ve added
>> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro
>> down to InitializePythonHome in
>> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
>> call Py_SetPythonHome with it. My installations have the python dll and
>> python library directory. We put the library in /lib/python35 and
>> the dll in /bin.
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com  ]
>> Sent: Wednesday, November 23, 2016 12:40 PM
>> To: Vadim Chugunov mailto:vadi...@gmail.com> >
>> Cc: Reid Kleckner mailto:r...@google.com> >; Hans Wennborg 
>> mailto:h...@chromium.org> >;
>> LLDB mailto:lldb-dev@lists.llvm.org> >; Ted 
>> Woodward mailto:ted.woodw...@codeaurora.org> >
>> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>
>>
>>
>> I believe the way to fix this is going to be building LLDB for the
>> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>
>>
>>
>> +Ted, since I believe he is one of the few people currently using this
>> flag.
>>
>> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov >  > wrote:
>>
>> This is still broken in the October snapshot.   Do you know which script
>> is used to build the Windows installer?
>>
>>
>>
>> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner >  >
>> wrote:
>>
>> I think it is a problem with the way we built lldb.  I will look into what
>> additional

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

2016-11-28 Thread Vadim Chugunov via lldb-dev 
Is there a tarball somewhere that I can pull those files out from?

I tried with an older build I have on my machine; and copying site-packages
over into %LLVM%\lib did allow lldb module loading to get a bit further,
but it still failed because SWIG-generated wrapper does not match the .pyd
module.

On Mon, Nov 28, 2016 at 10:28 AM, Zachary Turner  wrote:

> BTW, _lldb.pyd is just a symlink of liblldb.dll.  Perhaps you could try
> creating the symlink manually and copying the other files (e.g.
> embedded_interpreter.py, six.py, etc) over to see if it works.  If it does,
> it would at least confirm that this is everything we need to do to get it
> working for you, so that we can have some confidence the next release
> doesn't have the problems.
>
> On Mon, Nov 28, 2016 at 10:25 AM Vadim Chugunov  wrote:
>
>> At least on my machine, finding Python is not the problem, because Python
>> installer has added C:\Python35 to the PATH.  (It can also be found in the
>> Registry at
>> HKLM\SOFTWARE\Python\PythonCore\3.5-32\InstallPath).
>>
>>
>> On Mon, Nov 28, 2016 at 10:17 AM, Zachary Turner 
>> wrote:
>>
>> I overlooked that part of it, but yes that is another separate issue.
>>  (BTW, _lldb.pyd is simply a symlink to liblldb.dll).
>>
>> In any case, yea I think the entire lib/site-packages folder needs to be
>> included.
>>
>> On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov 
>> wrote:
>>
>> Please correct me if I'm wrong, but isn't the issue here that LLDB's
>> Python support files don't get packaged into the Windows installer?   Does
>> packaging them somehow depend on knowing what the Python installation path
>> is?
>>
>> On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg 
>> wrote:
>>
>> The snapshots are built with the script in
>> utils/release/build_llvm_package.bat. It's currently passing
>> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>>
>> I was planning on trying to build a new snapshot today and can add
>> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>>
>> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
>> wrote:
>> > So it sounds like you're saying that in order for Python support to
>> work as
>> > part of an LLDB shipped in the installer, we need to do set 3 variables
>> at
>> > CMake time.
>> >
>> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
>> > 2) -DPYTHON_HOME = 
>> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>> >
>> > Now because of #3, the lldb shipped in the installer will use the
>> PYTHONHOME
>> > system environment variable to locate python, which must point to a
>> valid
>> > Python 3.5 installation.  Is this correct?
>> >
>> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward <
>> ted.woodw...@codeaurora.org>
>> > wrote:
>> >>
>> >> Windows has no concept of a default python installation, and I can’t be
>> >> sure what version of python my users have, if any, so I need to solve 2
>> >> problems:
>> >>
>> >> 1)  Where is python when I’m building?
>> >>
>> >> 2)  Where is python when I’m running?
>> >>
>> >>
>> >>
>> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
>> my
>> >> python installation (on our buildbots, c:/python351).
>> >>
>> >>
>> >>
>> >> #2 only needs to be solved if the machine you’re running on doesn’t
>> have
>> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
>> added
>> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
>> macro
>> >> down to InitializePythonHome in
>> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp,
>> and
>> >> call Py_SetPythonHome with it. My installations have the python dll and
>> >> python library directory. We put the library in /lib/python35
>> and
>> >> the dll in /bin.
>> >>
>> >> --
>> >>
>> >> Qualcomm Innovation Center, Inc.
>> >>
>> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a
>> >> Linux Foundation Collaborative Project
>> >>
>> >>
>> >>
>> >> From: Zachary Turner [mailto:ztur...@google.com]
>> >> Sent: Wednesday, November 23, 2016 12:40 PM
>> >> To: Vadim Chugunov 
>> >> Cc: Reid Kleckner ; Hans Wennborg ;
>> >> LLDB ; Ted Woodward <
>> ted.woodw...@codeaurora.org>
>> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>> >>
>> >>
>> >>
>> >> I believe the way to fix this is going to be building LLDB for the
>> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>> >>
>> >>
>> >>
>> >> +Ted, since I believe he is one of the few people currently using this
>> >> flag.
>> >>
>> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
>> wrote:
>> >>
>> >> This is still broken in the October snapshot.   Do you know which
>> script
>> >> is used to build the Windows installer?
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>> >> wrote:
>> >>
>> >> I think it is a problem with the way we built lldb.  I will look into
>> what
>> >> additional steps we need to take when making the prebuilt binary so
>> that it
>> >> works next time.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 11, 2016 a

[lldb-dev] Sample output from Darwin / Linux timeout pre-kill hook?

2016-11-28 Thread Ed Maste via lldb-dev 
I'm looking at adding a FreeBSD timeout pre-kill hook, and I'm
interested in mirroring the data currently collected on Linux and OS
X. Is there a sample output from a timed-out LLDB test available
somewhere?

-Ed
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

2016-11-28 Thread Greg Clayton via lldb-dev 
One thing that we have talked about is to move the ProcessWindows stuff into 
lldb-server (it has a NativeProcess and NativeThread class you would need to 
subclass instead of making ProcessWindows and ThreadWindows classes) instead of 
making a native plug-in that is only useful on the current system. Then remote 
windows debugging would be possible. It would end up using thee 
ProcessGDBRemote.cpp process plug-in then. Then the ProcessWindows plugin 
directory would not be needed. Any thoughts on this?

Greg

> On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev 
>  wrote:
> 
> If you're not working in LLDB's Windows process plugin, you probably don't 
> care about this message.
> 
> FYI:  I'm doing some refactoring (actually unfactoring) in the Windows 
> process plugin.  It'll take a series patches over a few days next week.  If 
> you're planning on working in this area, please let me know so we can 
> coordinate.
> 
> Details:
> 
> Last year, I factored the classes like ProcessWindows into pairs of classes 
> with names like ProcessWindows and ProcessWindowsLive so that I could 
> introduce classes like ProcessWindowsMiniDump that shared common code.  Now 
> that the Windows-specific minidump plugin has been superseded by the 
> cross-platform minidump plugin, this factoring is no longer necessary.  Since 
> the factoring creates extra layers that make the code harder to understand 
> and maintain, I'd like to undo the split.
> 
> My plan is to do this in three NFC patches:
> 
> Patch 1.  Roll the functionality from the common classes into the -Live 
> classes.  This will eliminate everything under Plugins/Process/Windows/Common 
> and leave the functional code in Process/Plugins/Windows/Live.
> 
> Patch 2.  Rename the -Live classes to shorter, more tractable names.
> 
> Patch 3.  Move the code up from the Live subdirectory so that it once again 
> lives in Plugins/Process/Windows.
> 
> Patches 2 and 3 could be done in a single step, but I think the history will 
> be easier to follow if I keep them separate.
> 
> If you have any concerns about this plan, please let me know.
> 
> Adrian.
> 
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Refactoring in LLDB Windows Plugin

2016-11-28 Thread Adrian McCarthy via lldb-dev 
I have no objection to moving in that direction (enabling remote
debugging).  Zach just pointed out that we'd first have to port lldb-server
to Windows.  Offhand, I don't know how much of an effort that would be.

In the near-term, I'm focused on postmortem debugging, so this wouldn't be
a priority for me for a while.

The "unfactoring" I mentioned in this email is essentially done, though I'm
planning to move some files to eliminate an unnecessary subdirectory from
the source paths.

On Mon, Nov 28, 2016 at 12:43 PM, Greg Clayton  wrote:

> One thing that we have talked about is to move the ProcessWindows stuff
> into lldb-server (it has a NativeProcess and NativeThread class you would
> need to subclass instead of making ProcessWindows and ThreadWindows
> classes) instead of making a native plug-in that is only useful on the
> current system. Then remote windows debugging would be possible. It would
> end up using thee ProcessGDBRemote.cpp process plug-in then. Then the
> ProcessWindows plugin directory would not be needed. Any thoughts on this?
>
> Greg
>
> > On Nov 18, 2016, at 4:00 PM, Adrian McCarthy via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > If you're not working in LLDB's Windows process plugin, you probably
> don't care about this message.
> >
> > FYI:  I'm doing some refactoring (actually unfactoring) in the Windows
> process plugin.  It'll take a series patches over a few days next week.  If
> you're planning on working in this area, please let me know so we can
> coordinate.
> >
> > Details:
> >
> > Last year, I factored the classes like ProcessWindows into pairs of
> classes with names like ProcessWindows and ProcessWindowsLive so that I
> could introduce classes like ProcessWindowsMiniDump that shared common
> code.  Now that the Windows-specific minidump plugin has been superseded by
> the cross-platform minidump plugin, this factoring is no longer necessary.
> Since the factoring creates extra layers that make the code harder to
> understand and maintain, I'd like to undo the split.
> >
> > My plan is to do this in three NFC patches:
> >
> > Patch 1.  Roll the functionality from the common classes into the -Live
> classes.  This will eliminate everything under
> Plugins/Process/Windows/Common and leave the functional code in
> Process/Plugins/Windows/Live.
> >
> > Patch 2.  Rename the -Live classes to shorter, more tractable names.
> >
> > Patch 3.  Move the code up from the Live subdirectory so that it once
> again lives in Plugins/Process/Windows.
> >
> > Patches 2 and 3 could be done in a single step, but I think the history
> will be easier to follow if I keep them separate.
> >
> > If you have any concerns about this plan, please let me know.
> >
> > Adrian.
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] December LLVM bay-area social is this Thursday!

2016-11-28 Thread George Burgess IV via lldb-dev 
We'll be at Tied House as usual, starting on Thursday the 1st at 7pm!

If you can, help us plan and RSVP here: http://meetu.ps/31LkwJ

See everyone there! (And if you can't make it, early happy holidays :) )
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev