[lldb-dev] [Bug 16610] LLDB Linux CMake build requires Python >= 2.7

2016-04-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=16610

Vince Harron  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||vi...@nethacker.com
 Resolution|--- |WONTFIX

-- 
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] [Bug 27441] New: Bot failure: lldb-python-test-suite fails to run (LLDB, using Stage 1 RA)

2016-04-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=27441

Bug ID: 27441
   Summary: Bot failure: lldb-python-test-suite fails to run
(LLDB, using Stage 1 RA)
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: v...@apple.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Bot name: LLDB, using Stage 1 RA

URL: http://lab.llvm.org:8080/green/job/lldb_build_test/17819/consoleText

Problem:

=== BUILD LEGACY TARGET lldb-python-test-suite OF PROJECT lldb WITH
CONFIGURATION Debug ===

Check dependencies

ExternalBuildToolExecution lldb-python-test-suite
cd "/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products"
export ACTION=
/usr/bin/python -u
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py --apple-sdk
macosx
--executable=/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/Debug/lldb
-C
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/llvm-build/Release+Asserts/x86_64/bin/clang
--results-formatter lldbsuite.test.xunit_formatter.XunitFormatter
--results-file
/Users/buildslave/jenkins/sharedspace/lldb@2/lldb-build/Build/Products/test-results.xml
--rerun-all-issues --env TERM=vt100 -O--xpass=ignore
Traceback (most recent call last):
  File "/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/test/dotest.py", line
7, in 
lldbsuite.test.run_suite()
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/dotest.py",
line 872, in run_suite
setupTestResults()
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test/dotest.py",
line 463, in setupTestResults
formatter_config)
  File
"/Users/buildslave/jenkins/sharedspace/lldb@2/lldb/packages/Python/lldbsuite/test_event/formatter/__init__.py",
line 127, in create_results_formatter
module = importlib.import_module(".".join(components[:-1]))
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
line 37, in import_module
__import__(name)
ImportError: No module named xunit_formatter
Command /usr/bin/python failed with exit code 1

** BUILD FAILED **


The following build commands failed:
ExternalBuildToolExecution lldb-python-test-suite

-- 
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] [Bug 27441] Bot failure: lldb-python-test-suite fails to run (LLDB, using Stage 1 RA)

2016-04-20 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=27441

Vedant Kumar  changed:

   What|Removed |Added

   Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com

-- 
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] UnicodeDecodeError for serialize SBValue description

2016-04-20 Thread Jeffrey Tan via lldb-dev 
Hi Enrico,

Instead of trying function-evaluation c_str(), I decided to decode the
information from fbstring_core fields. I got it working but have two
questions for it.

type summary add -F data_formatter.folly_string_formatter -x
"std::fbstring_core"

Here is the output:

fr v -T small
(std::string) small = "small"

fr v -T small.store_
(std::fbstring_core) small.store_ = None

fr v -T small.store_.ml_
(std::fbstring_core::MediumLarge) small.store_.ml_ = None

Questions:
1. Even I only added formatter for std::fbstring_core why does it
work for std::string?
2. Why the later small.store_ and small.store_.ml_ will show summary None
now? I would not expect the data formatter will happen to them.

Btw: here is the implementation of fbstring_core
https://github.com/facebook/folly/blob/master/folly/FBString.h

Thanks
Jeffrey

On Wed, Apr 13, 2016 at 11:08 AM, Enrico Granata  wrote:

> In theory what you're doing looks like it should be supported. I am not
> sure why your example is failing the way it is.
>
> Is your variable a global maybe?
>
> Also, using the variable name is the wrong thing to do. If you have a
> class with a std::string member, the name is going to return the wrong
> thing. You would want to at least use the expression path - and even then
> there are some cases where we can't cons up a proper expression path.
>
> Sent from my iPhone
>
> On Apr 13, 2016, at 11:02 AM, Jeffrey Tan  wrote:
>
> I did a quick testing to call SBFrame.EvaluateExpression('string.c_str()')
> for the summary. The result shows valobj.GetFrame() returns None so does
> this mean this is not supported?
>
> def DoTest(valobj,internal_dict):
> print "valobj: %s" % valobj
> print "valobj.GetFrame(): %s" % valobj.GetFrame()
> summaryValue = valobj.GetFrame().EvaluateExpression(valobj.name +
> '.c_str()')
> print "summaryValue: %s" % summaryValue
> return 'Summary from c_str(): %s ' % summaryValue.GetSummary()
>
> type summary add -F DoTest -x "std::fbstring_core"
>
> Output:
> valobj.GetFrame(): No value
> summaryValue: No value
> valobj: (std::string) $6 = {
>   store_ = Summary from c_str(): None
> }
>
> Jeffrey
>
> On Wed, Apr 13, 2016 at 10:11 AM, Jeffrey Tan 
> wrote:
>
>> One quick question: do we support getting type summary string from
>> inferior method call? After reading our own fbstring_core code, I found I
>> need to mirror a lot of what fbstring_core.c_str() method is doing in
>> python. I wonder if we can just call ${var.c_str()} as the type summary? I
>> suspect one of the concern is side-effect(the inferior method may throw
>> exception or cause problems) but I would not see why this can't be done. By
>> allowing this we can keep the data formatter truth one copy(in source code)
>> instead of potential out-of-sync(let say the std::string author decided to
>> change it implementation, the python data formatter associated with it
>> needs to be modified at the same time which is a maintain nightmare).
>>
>> Jeffrey
>>
>> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata 
>> wrote:
>>
>>>
>>> On Apr 6, 2016, at 7:31 PM, Jeffrey Tan  wrote:
>>>
>>> Thanks Enrico. This is very detailed! I will take a look.
>>> Btw: originally, I was hoping that data formatter can be added without
>>> changing the source code. Like giving a xml/json format file telling lldb
>>> the memory layout/structure of the data structure, lldb can parse the
>>> xml/json and deduce the formatting. This is approach used by data
>>> visualizer in VS debugger:
>>> https://msdn.microsoft.com/en-us/library/jj620914.aspx
>>> This will make adding data formatter more extensible/flexible. Any
>>> reason we did not take this approach?
>>>
>>>
>>> The way I understand the Natvis system, it allows one to provide a bunch
>>> of expressions that describe how the debugger would go about retrieving the
>>> interesting data bits
>>> This has the bonus of being really easy, since you’re writing code in
>>> the same language/context of the types you’re formatting
>>> On the other hand it has a few drawbacks, in terms of performance as
>>> well as safety (imagine trying to run code on an object when said object is
>>> in an incoherent state)
>>> The LLDB approach, on the other hand, is that you should try to not run
>>> code when providing these data formatters. In order to do that, we vend an
>>> API that can do things such as retrieve child values, read memory, cast
>>> values, …, all without code execution
>>> Once you have this kind of API that is not expressed in your source
>>> language, you might just as well describe it in a scripting language. Hence
>>> were born the Python data formatters.
>>> In order for us to gain even more performance for native system types
>>> that we know we’re gonna run into all the time, we then switched a bunch of
>>> the “mission critical” formatters from Python to C++
>>> The Python extension points are still available, as Jim pointed out, and
>>> you are more than welcome to use those instead of modifyin

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

2016-04-20 Thread Enrico Granata via lldb-dev 

> On Apr 20, 2016, at 3:08 PM, Jeffrey Tan  wrote:
> 
> Hi Enrico,
> 
> Instead of trying function-evaluation c_str(), I decided to decode the 
> information from fbstring_core fields. I got it working but have two 
> questions for it.
> 
> type summary add -F data_formatter.folly_string_formatter -x 
> "std::fbstring_core"
> 
> Here is the output:
> 
> fr v -T small
> (std::string) small = "small"
> 
> fr v -T small.store_
> (std::fbstring_core) small.store_ = None
> 
> fr v -T small.store_.ml_
> (std::fbstring_core::MediumLarge) small.store_.ml_ = None
> 
> Questions:
> 1. Even I only added formatter for std::fbstring_core why does it work 
> for std::string?
> 2. Why the later small.store_ and small.store_.ml_ will show summary None 
> now? I would not expect the data formatter will happen to them.

Using “-x” means you added a summary for every type that matches the regular 
expression “std::fbstring_core”
If you seriously only want to match “std::fbstring_core”, you should 
leave out the “-x” argument
That should solve the third problem you are running into

As for the first issue - I am not sure - I’d need to look at the 
data_formatter.py file

> 
> Btw: here is the implementation of fbstring_core 
> https://github.com/facebook/folly/blob/master/folly/FBString.h 
> 
> 
> Thanks
> Jeffrey
> 
> On Wed, Apr 13, 2016 at 11:08 AM, Enrico Granata  > wrote:
> In theory what you're doing looks like it should be supported. I am not sure 
> why your example is failing the way it is.
> 
> Is your variable a global maybe?
> 
> Also, using the variable name is the wrong thing to do. If you have a class 
> with a std::string member, the name is going to return the wrong thing. You 
> would want to at least use the expression path - and even then there are some 
> cases where we can't cons up a proper expression path.
> 
> Sent from my iPhone
> 
> On Apr 13, 2016, at 11:02 AM, Jeffrey Tan  > wrote:
> 
>> I did a quick testing to call SBFrame.EvaluateExpression('string.c_str()') 
>> for the summary. The result shows valobj.GetFrame() returns None so does 
>> this mean this is not supported?
>> 
>> def DoTest(valobj,internal_dict):
>> print "valobj: %s" % valobj
>> print "valobj.GetFrame(): %s" % valobj.GetFrame()
>> summaryValue = valobj.GetFrame().EvaluateExpression(valobj.name 
>>  + '.c_str()')
>> print "summaryValue: %s" % summaryValue
>> return 'Summary from c_str(): %s ' % summaryValue.GetSummary()
>> 
>> type summary add -F DoTest -x "std::fbstring_core"
>> 
>> Output:
>> valobj.GetFrame(): No value
>> summaryValue: No value
>> valobj: (std::string) $6 = {
>>   store_ = Summary from c_str(): None
>> }
>> 
>> Jeffrey
>> 
>> On Wed, Apr 13, 2016 at 10:11 AM, Jeffrey Tan > > wrote:
>> One quick question: do we support getting type summary string from inferior 
>> method call? After reading our own fbstring_core code, I found I need to 
>> mirror a lot of what fbstring_core.c_str() method is doing in python. I 
>> wonder if we can just call ${var.c_str()} as the type summary? I suspect one 
>> of the concern is side-effect(the inferior method may throw exception or 
>> cause problems) but I would not see why this can't be done. By allowing this 
>> we can keep the data formatter truth one copy(in source code) instead of 
>> potential out-of-sync(let say the std::string author decided to change it 
>> implementation, the python data formatter associated with it needs to be 
>> modified at the same time which is a maintain nightmare). 
>> 
>> Jeffrey
>> 
>> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata > > wrote:
>> 
>>> On Apr 6, 2016, at 7:31 PM, Jeffrey Tan >> > wrote:
>>> 
>>> Thanks Enrico. This is very detailed! I will take a look. 
>>> Btw: originally, I was hoping that data formatter can be added without 
>>> changing the source code. Like giving a xml/json format file telling lldb 
>>> the memory layout/structure of the data structure, lldb can parse the 
>>> xml/json and deduce the formatting. This is approach used by data 
>>> visualizer in VS debugger: 
>>> https://msdn.microsoft.com/en-us/library/jj620914.aspx 
>>> 
>>> This will make adding data formatter more extensible/flexible. Any reason 
>>> we did not take this approach? 
>>> 
>> 
>> The way I understand the Natvis system, it allows one to provide a bunch of 
>> expressions that describe how the debugger would go about retrieving the 
>> interesting data bits
>> This has the bonus of being really easy, since you’re writing code in the 
>> same language/context of the types you’re formatting
>> On the other hand it has a few drawbacks, in terms of performance as well as 
>> safety (imagine trying to run code on an object when said object

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

2016-04-20 Thread Jeffrey Tan via lldb-dev 
After removing the "-x" and apply the formatter to "std::string" instead of
fbstring_core, it works fine now. Thanks!

On Wed, Apr 20, 2016 at 3:24 PM, Enrico Granata  wrote:

>
> On Apr 20, 2016, at 3:08 PM, Jeffrey Tan  wrote:
>
> Hi Enrico,
>
> Instead of trying function-evaluation c_str(), I decided to decode the
> information from fbstring_core fields. I got it working but have two
> questions for it.
>
> type summary add -F data_formatter.folly_string_formatter -x
> "std::fbstring_core"
>
> Here is the output:
>
> fr v -T small
> (std::string) small = "small"
>
> fr v -T small.store_
> (std::fbstring_core) small.store_ = None
>
> fr v -T small.store_.ml_
> (std::fbstring_core::MediumLarge) small.store_.ml_ = None
>
> Questions:
> 1. Even I only added formatter for std::fbstring_core why does it
> work for std::string?
> 2. Why the later small.store_ and small.store_.ml_ will show summary None
> now? I would not expect the data formatter will happen to them.
>
>
> Using “-x” means you added a summary for every type that matches the
> regular expression “std::fbstring_core”
> If you seriously only want to match “std::fbstring_core”, you should
> leave out the “-x” argument
> That should solve the third problem you are running into
>
> As for the first issue - I am not sure - I’d need to look at the
> data_formatter.py file
>
>
> Btw: here is the implementation of fbstring_core
> https://github.com/facebook/folly/blob/master/folly/FBString.h
>
> Thanks
> Jeffrey
>
> On Wed, Apr 13, 2016 at 11:08 AM, Enrico Granata 
> wrote:
>
>> In theory what you're doing looks like it should be supported. I am not
>> sure why your example is failing the way it is.
>>
>> Is your variable a global maybe?
>>
>> Also, using the variable name is the wrong thing to do. If you have a
>> class with a std::string member, the name is going to return the wrong
>> thing. You would want to at least use the expression path - and even then
>> there are some cases where we can't cons up a proper expression path.
>>
>> Sent from my iPhone
>>
>> On Apr 13, 2016, at 11:02 AM, Jeffrey Tan 
>> wrote:
>>
>> I did a quick testing to call
>> SBFrame.EvaluateExpression('string.c_str()') for the summary. The result
>> shows valobj.GetFrame() returns None so does this mean this is not
>> supported?
>>
>> def DoTest(valobj,internal_dict):
>> print "valobj: %s" % valobj
>> print "valobj.GetFrame(): %s" % valobj.GetFrame()
>> summaryValue = valobj.GetFrame().EvaluateExpression(valobj.name +
>> '.c_str()')
>> print "summaryValue: %s" % summaryValue
>> return 'Summary from c_str(): %s ' % summaryValue.GetSummary()
>>
>> type summary add -F DoTest -x "std::fbstring_core"
>>
>> Output:
>> valobj.GetFrame(): No value
>> summaryValue: No value
>> valobj: (std::string) $6 = {
>>   store_ = Summary from c_str(): None
>> }
>>
>> Jeffrey
>>
>> On Wed, Apr 13, 2016 at 10:11 AM, Jeffrey Tan 
>> wrote:
>>
>>> One quick question: do we support getting type summary string from
>>> inferior method call? After reading our own fbstring_core code, I found I
>>> need to mirror a lot of what fbstring_core.c_str() method is doing in
>>> python. I wonder if we can just call ${var.c_str()} as the type summary? I
>>> suspect one of the concern is side-effect(the inferior method may throw
>>> exception or cause problems) but I would not see why this can't be done. By
>>> allowing this we can keep the data formatter truth one copy(in source code)
>>> instead of potential out-of-sync(let say the std::string author decided to
>>> change it implementation, the python data formatter associated with it
>>> needs to be modified at the same time which is a maintain nightmare).
>>>
>>> Jeffrey
>>>
>>> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata 
>>> wrote:
>>>

 On Apr 6, 2016, at 7:31 PM, Jeffrey Tan 
 wrote:

 Thanks Enrico. This is very detailed! I will take a look.
 Btw: originally, I was hoping that data formatter can be added without
 changing the source code. Like giving a xml/json format file telling lldb
 the memory layout/structure of the data structure, lldb can parse the
 xml/json and deduce the formatting. This is approach used by data
 visualizer in VS debugger:
 https://msdn.microsoft.com/en-us/library/jj620914.aspx
 This will make adding data formatter more extensible/flexible. Any
 reason we did not take this approach?


 The way I understand the Natvis system, it allows one to provide a
 bunch of expressions that describe how the debugger would go about
 retrieving the interesting data bits
 This has the bonus of being really easy, since you’re writing code in
 the same language/context of the types you’re formatting
 On the other hand it has a few drawbacks, in terms of performance as
 well as safety (imagine trying to run code on an object when said object is
 in an incoherent state)
 The LLDB approach, on the other hand, is that you should try