[lldb-dev] [Bug 26363] lldb 3.8.0.rc1 fails to build out of llvm tree

2016-09-13 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=26363

lab...@google.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lab...@google.com
 Resolution|--- |FIXED

--- Comment #1 from lab...@google.com ---
This should be fixed in r281317

-- 
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

[lldb-dev] lldb type summary provider - SBProcess is invalid

2016-09-13 Thread Lei Kong via lldb-dev 
I wrote a lldb type summary provider for wstring with 16bit wchar on Ubuntu 
16.04.Things work fine if I manually do the following in lldb:(lldb) script 
import mytypes
(lldb) type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
I tried to make things easier with auto-loading by adding the following to 
.lldbinit:script import mytypes
type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
Then I got a failure of "SBProcess is invalid" when printing a wstring 
variable.My type summary function has the following, which I believe is where 
the error is encountered:content = lldb.process.ReadMemory(bufferAddr, 
byteCount, error)
Maybe this is because "process" is not assigned yet when the type summary is 
added during auto-loading? Or this is a bug in lldb? Does anyone know how to 
work around this issue? Thanks much 
  ___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb type summary provider - SBProcess is invalid

2016-09-13 Thread Enrico Granata via lldb-dev 

> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev  
> wrote:
> 
> I wrote a lldb type summary provider for wstring with 16bit wchar on Ubuntu 
> 16.04.
> 
> Things work fine if I manually do the following in lldb:
> 
> (lldb) script import mytypes
> (lldb) type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> I tried to make things easier with auto-loading by adding the following to 
> .lldbinit:
> 
> script import mytypes
> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> Then I got a failure of "SBProcess is invalid" when printing a wstring 
> variable.
> 
> My type summary function has the following, which I believe is where the 
> error is encountered:
> 
> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
> Maybe this is because "process" is not assigned yet when the type summary is 
> added during auto-loading? Or this is a bug in lldb? Does anyone know how to 
> work around this issue?
> 
> 

Good hunch :-)
Maybe we should do a better job at documenting this, but 
http://lldb.llvm.org/python-reference.html 
 reads

"While extremely convenient, these variables (lldb.process et alia) have a 
couple caveats that you should be aware of. First of all, they hold the values 
of the selected objects on entry to the embedded interpreter. They do not 
update as you use the LLDB API's to change, for example, the currently selected 
stack frame or thread. 
Moreover, they are only defined and meaningful while in the interactive Python 
interpreter. There is no guarantee on their value in any other situation, hence 
you should not use them when defining Python formatters, breakpoint scripts and 
commands (or any other Python extension point that LLDB provides). As a 
rationale for such behavior, consider that lldb can run in a multithreaded 
environment, and another thread might call the "script" command, changing the 
value out from under you."

As part of a formatter, you get passed an SBValue. One of the things you can 
ask of an SBValue is the process it came from, thusly:

value.GetProcess()

That's the SBProcess object you want to use

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

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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

Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-13 Thread Chris Bieneman via lldb-dev 

> On Sep 10, 2016, at 12:11 PM, René J.V. Bertin via lldb-dev 
>  wrote:
> 
> On Saturday September 10 2016 17:26:26 Michał Górny wrote:
> 
> Re: MIUtilParse: I'm building the 3.9.0 release so no worries that the class 
> has been added back supposing it was removed *after* the release.
> 
>>> Agree that a standalone build would be great to have working, it just
>>> requires someone willing and able to come along and fix it :)
>> 
>> I have it on my TODO but honestly speaking, LLDB is a bit of a mess
>> right now and I'm not even sure where to start. So far I'm focusing
>> on the other LLVM components but I should be able to get to LLDB soon.
>> Though I can't promise much since my time is quite limited.
> 
> There really isn't much to be done to get it to work, esp. if the 
> abovementioned class is already removed:
> 
> - fix finding CheckAtomic.cmake (or just install it with LLVM)

CheckAtomic is installed with LLVM on trunk, and will be this way in future 
releases.

> - fix the install location as recorded in liblldb and make sure that location 
> gets added to the rpath in lldb, lldb-mi and other dependents.
> 
> There's also an issue finding the proper Python library, at least when 
> building MacPorts. It finds the correct framework binary when doing a 
> complete build using the toplevel CMake file, but apparently goes for the 
> latest version if you use the standalone build.
> 
> R.
> ___
> 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] Python3 compatibility for the API

2016-09-13 Thread Ted Woodward via lldb-dev 
I just built lldb on Ubuntu 12 with Python 3.5.1. I needed to set python 
includes, python library and python executable in cmake.

I found a problem with the tests - most ran fine, but I got errors with tests 
that tried to use pexpect, like TestConvenienceVariables.py.
  File 
"/local/scratch/ted/8.1/llvm/tools/lldb/third_party/Python/module/pexpect-2.4/pexpect.py",
 line 82
except ImportError, e:
  ^
SyntaxError: invalid syntax

If we want to run the tests with Python3 we'll need to update pexpect.

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


-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Luke 
Drummond via lldb-dev
Sent: Tuesday, August 30, 2016 7:01 AM
To: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] Python3 compatibility for the API

Hi Zachary, Peter

On 30/08/16 00:14, Zachary Turner via lldb-dev wrote:
> Right, the existing version that is built and what you are using links 
> directly against a 2.7 libpython at compile time.  So you would 
> probably need to build LLDB from source and tweak the build system to 
> make it possible to link against your 3.x version of python.  There's 
> some build instructions on the website 
> .  I know there's a few linux 
> developers around here, so it's possible someone else would be 
> interested in making this work as well, but I don't know that it's on 
> anyone's immediate timeline.

We build lldb against python3 regularly, because - as Zachary said - this is 
the only way to get scripting support on windows. To link against python3 on 
Linux you *should* just need the correct headers installed, and invoke CMake 
with the correct python path. For Ubuntu:

```
sudo apt install python3-dev
cmake "$PATH_TO_LLVM_SRC" -DPYTHON_EXECUTABLE:FILEPATH=$(which python3) ```

*should* give you everything you need. However, you may see that cmake picks up 
the python3 interpreter correctly, but tries to link against the python2.7 
library.

-- Found PythonInterp: /usr/bin/python3 (found version "3.5.2") [...]
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found version 
"2.7.12")

This appears to be due to a problem in LLVM's CMakeLists.txt specifying support 
for 2.7 only. I have a patch to fix the issue awaiting review
[here](https://reviews.llvm.org/D20825) which should fix the issue on Linux 
when multiple pythons are installed. It may be worth applying this patch 
locally and see how you get on.

Hope that helps

Best

Luke
___
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 type summary provider - SBProcess is invalid

2016-09-13 Thread Lei Kong via lldb-dev 
Thanks!
SBValue.process works!

I have another script that I run manually to search process memory for certain 
patterns, not a type summary provider, there is no SBValue passed to my script, 
in such a case, how do I get current process?

From: Enrico Granata
Sent: Tuesday, September 13, 2016 10:31 AM
To: Lei Kong
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid


> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev  
> wrote:
>
> I wrote a lldb type summary provider for wstring with 16bit wchar on Ubuntu 
> 16.04.
>
> Things work fine if I manually do the following in lldb:
>
> (lldb) script import mytypes
> (lldb) type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> I tried to make things easier with auto-loading by adding the following to 
> .lldbinit:
>
> script import mytypes
> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring"
> Then I got a failure of "SBProcess is invalid" when printing a wstring 
> variable.
>
> My type summary function has the following, which I believe is where the 
> error is encountered:
>
> content = lldb.process.ReadMemory(bufferAddr, byteCount, error)
> Maybe this is because "process" is not assigned yet when the type summary is 
> added during auto-loading? Or this is a bug in lldb? Does anyone know how to 
> work around this issue?
>
>

Good hunch :-)
Maybe we should do a better job at documenting this, but 
http://lldb.llvm.org/python-reference.html 
 reads

"While extremely convenient, these variables (lldb.process et alia) have a 
couple caveats that you should be aware of. First of all, they hold the values 
of the selected objects on entry to the embedded interpreter. They do not 
update as you use the LLDB API's to change, for example, the currently selected 
stack frame or thread.
Moreover, they are only defined and meaningful while in the interactive Python 
interpreter. There is no guarantee on their value in any other situation, hence 
you should not use them when defining Python formatters, breakpoint scripts and 
commands (or any other Python extension point that LLDB provides). As a 
rationale for such behavior, consider that lldb can run in a multithreaded 
environment, and another thread might call the "script" command, changing the 
value out from under you."

As part of a formatter, you get passed an SBValue. One of the things you can 
ask of an SBValue is the process it came from, thusly:

value.GetProcess()

That's the SBProcess object you want to use

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

Thanks,
- Enrico
📩 egranata@.com ☎️ 27683

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