Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Enrico Granata via lldb-dev]

> On Nov 18, 2015, at 10:34 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> 
> 
> On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala  > wrote:
> Checking in the static bindings is no different than projects checking in 
> autoconf config baked scripts so that the vast majority of people don't need 
> to run autoconf just to get a setup that rarely changes.  There is precedent 
> for this going back a long way on open source projects.
> 
> I'm backing off having anyone else use them if they don't want, and we 
> (Apple) will keep those up to date.  Nobody else will use them.  Totally fine.
> 
> On the swig-as-a-service front, I think the idea is interesting but there are 
> several practical holes with that:
> 
> * What does one do when the server is unavailable?  Needs to be a local-only 
> backup.  So whatever service that provides isn't a guaranteed working 
> solution (think on an airplane, network outage, other server outage, etc.)
> 
> * Security: building code that has other code injected in it by another 
> server. Safe? Attack vector?  I could argue so is a git/svn repo susceptible 
> to this, so maybe this isn't a huge deal, but it's big enough and smells 
> enough like "introduce random unvetted code that can't be reviewed as easily 
> as a VCS tag" that I doubt we would ever use this in practice.
> 
> * Security 2: what is the service really running?  Not obvious on the build 
> machine accessing the service.
> The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py 
> that you check into the repo.  You still have a chance to diff this source 
> code against the repository's copy before committing, same as you would if 
> you had swig locally.  Vast majority of changes to SB interfaces are going to 
> be the addition of a couple methods, or maybe a class, and the diff should be 
> very easy to look at and understand.
>  
> 
> > In all of these cases (except the proposed), the matrix choices are 
> > justifiable because they are there to support a hard requirement of 
> > someone's environment, and I do not think we should grow for anything that 
> > is not also a hard requirement of someone's environment.  
> 
> I'm going to call that overreaching.  We are not in the business of dictating 
> that one of the developers of the code "should not do something unless there 
> is a hard requirement."
> I'm not saying you shouldn't do *anything* if there's not a hard requirement. 
>  I agree that's overreaching.  I'm saying we should not increase the number 
> of ways of doing *the same thing* unless there is a hard requirement.  
> Especially if one of the ways of doing the same thing exists solely to save 
> someone from running one command to install the package (sorry if I'm not 
> doing justice to how difficult it is on OSX, the last time I did something on 
> OSX it seemed fairly easy to install macports, and I thought it's a wildly 
> common thing for people to already have installed).  For example, wouldn't 
> people need to already have macports in order to install CMake -- a necessary 
> component of building LLVM?

CMake vends binary packages on OS X, along with installation instructions, so 
actually, you don’t need hombrew to get CMake on OS X. On my work machines, I 
actually don’t have it installed at all.

>  
>  Apple wants to eliminate the need for people to *require* swig.  The goal 
> there is reducing the build requirements for the average person building 
> lldb, not growing it.
> I agree, which is why it is so important to keep the number of different ways 
> of building to a minimum.  It's the same reason that the autoconf build is 
> being removed wholesale from LLVM and people have decided that CMake is the 
> one true way.  Because even if it isn't perfect for everyone, it works for 
> everyone.  And there is inherent simplicity in having fewer ways to do 
> things, as well as reducing maintenance cost.
>  
> 
> So for the more common, casual lldb build environment where the developer is 
> not touching SB API, help me understand how reducing the need for swig 
> (without introducing the need for hitting another server) is increasing the 
> requirement load?  (Especially if we --- our local dev group sitting by me 
> --- maintains those static bindings)?
> 
> Well, we would need to disable static bindings on the OSX buildbots for 
> starters, otherwise when someone not using static bindings makes a change, 
> the buildbots break, and we cannot leave buildbots in a broken state.  So I 
> assume that will still be possible.  So now you don't have a buildbot testing 
> the static binding configuration.  
> 
> Secondly, LLDB already has a problem (IMHO) of having too many things that 
> only work for a few people, instead of having things that work for everyone.  
> It's gotten better, and even your work right now to port the Xcode build over 
> to these new python scripts is helping to make that better.  So regardless of 
> the outcome her

Re: [lldb-dev] Benchmark tests

[Enrico Granata via lldb-dev]

I have actually added a few benchmark tests recently. We admittedly are not 
that good with running those tests ever (because they're not run by default 
most likely - and I do wonder if some of them would take a long time to run.. I 
don't think I have ever run the full set, just my own as I increment on 
performance work).

Maybe we could try flipping the default to be "run the benchmarks", see if test 
suite run times explode and take it from there in terms of feasibility as well 
as whether they all still make sense.

The other problem with the tests as they stand is that they mark themselves as 
PASS or FAIL purely on the basis of whether they encounter command or API 
errors, and do nothing to track performance regressions. That is admittedly a 
harder problem to tackle given heterogeneous hardware and workload - but maybe 
we could have them fail if the timings go wildly crazy over some threshold?

Sent from my iPhone

> On Dec 9, 2015, at 1:22 PM, Todd Fiala via lldb-dev  
> wrote:
> 
> Hey Jason,
> 
> Are you the benchmark user?
> 
> -Todd
> 
>> On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev 
>>  wrote:
>> Is anyone using the benchmark tests?  None of the command line options 
>> related to the benchmark tests were claimed as being used by anyone.  Which 
>> makes me wonder if the tests are even being used by anyone.  
>> 
>> What I really want to know is: Is it really ok to delete the -x and -y 
>> command line options?  And what is the status of these tests?  Does anyone 
>> use them?
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> -- 
> -Todd
> ___
> 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] Benchmark tests

[Enrico Granata via lldb-dev]

Historically I would do

$ ./dotest.py +b 

but I am not strongly attached to that workflow - it's just what I learnt the 
first time I needed to run one

Sent from my iPhone

> On Dec 9, 2015, at 2:08 PM, Zachary Turner  wrote:
> 
> When you do run the benchmark tests, what command line options do you use?  
> At the moment I'm mostly just trying to remove dead options from the test 
> suite.  I removed one already that allowed you to specify the benchmark 
> executable, but then when I started looking at the rest and seeing how 
> tightly integrated they are with the benchamrk tests in general, I started to 
> wonder.
> 
> The three benchmark related command line options are:
> 
> 1. An option to specify the benchmark executable (defaults to lldb.exe)
> 2. An option to specify the breakpoint spec (defaults to -n main)
> 3. An option to specify the breakpoint iteration count (defaults to 30 I 
> think)
> 4. An option to specify that you only want to run benchmark tests and no 
> other tests.
> 
> I deleted #4 because you can use the category system for that.  I deleted #1 
> because nobody said they needed it on the spreadsheet.  Nobody said they 
> needed #2 or #3 either, but I just want to double check that deleting them is 
> fine.
> 
>> On Wed, Dec 9, 2015 at 2:01 PM Enrico Granata  wrote:
>> I have actually added a few benchmark tests recently. We admittedly are not 
>> that good with running those tests ever (because they're not run by default 
>> most likely - and I do wonder if some of them would take a long time to 
>> run.. I don't think I have ever run the full set, just my own as I increment 
>> on performance work).
>> 
>> Maybe we could try flipping the default to be "run the benchmarks", see if 
>> test suite run times explode and take it from there in terms of feasibility 
>> as well as whether they all still make sense.
>> 
>> The other problem with the tests as they stand is that they mark themselves 
>> as PASS or FAIL purely on the basis of whether they encounter command or API 
>> errors, and do nothing to track performance regressions. That is admittedly 
>> a harder problem to tackle given heterogeneous hardware and workload - but 
>> maybe we could have them fail if the timings go wildly crazy over some 
>> threshold?
>> 
>> Sent from my iPhone
>> 
>>> On Dec 9, 2015, at 1:22 PM, Todd Fiala via lldb-dev 
>>>  wrote:
>>> 
>>> Hey Jason,
>>> 
>>> Are you the benchmark user?
>>> 
>>> -Todd
>>> 
 On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev 
  wrote:
 Is anyone using the benchmark tests?  None of the command line options 
 related to the benchmark tests were claimed as being used by anyone.  
 Which makes me wonder if the tests are even being used by anyone.  
 
 What I really want to know is: Is it really ok to delete the -x and -y 
 command line options?  And what is the status of these tests?  Does anyone 
 use them?
 
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>>> 
>>> 
>>> -- 
>>> -Todd
>>> ___
>>> 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] Fwd: Enrico abroad for 2 weeks

[Enrico Granata via lldb-dev]

Sending again to right audience since I suspect most LLVM folks don’t really 
care :-)

> Begin forwarded message:
> 
> From: Enrico Granata 
> Subject: Enrico abroad for 2 weeks
> Date: December 21, 2015 at 3:29:51 PM PST
> To: llvm-...@lists.llvm.org
> 
> Hi,
> some of you may know this already - but anyway here goes
> 
> I am going to be abroad for 2 weeks starting tomorrow - away from keyboard 
> and with very restricted network access
> As such, I will take longer than usual to review patches and respond to 
> concerns
> 
> I will be back to the United States on January 6 2016.
> 
> Till then, happy holiday season to everyone!
> 
> - 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] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> Hi,
> If I have an SBValue for an object whose type has a formatter enabled for it, 
> is there a way to detect this via the Python API, and if so, request an 
> "unmodified" view of the object?

There definitely is a way for synthetic children, as you discovered below
For type formats, you can simply set the format on the SBValue on an individual 
basis (SBValue::SetFormat)
As for summaries, no, there is no way, as that would be nonsensical (don’t like 
the summary? just don’t ask for it - but there’s no meaning to getting the 
summary of a value once you disabled its summary)

> I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(), 
> but the former seems to always return false, and the latter gives me the same 
> list of children as the original value.

Do you have a reproduction case I can look at?
GetNonSyntheticValue() returning self is correct behavior if IsSynthetic() == 
False; but if there really is a synthetic provider attached to the object, 
IsSynthetic() should definitely return True

> 
> Thanks!
> ___
> 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] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 3:20 PM, Vadim Chugunov  wrote:
> 
> On Mon, Jan 25, 2016 at 11:04 AM, Enrico Granata  > wrote:
> 
>> On Jan 25, 2016, at 12:23 AM, Vadim Chugunov via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi,
>> If I have an SBValue for an object whose type has a formatter enabled for 
>> it, is there a way to detect this via the Python API, and if so, request an 
>> "unmodified" view of the object?
> 
> There definitely is a way for synthetic children, as you discovered below
> For type formats, you can simply set the format on the SBValue on an 
> individual basis (SBValue::SetFormat)
> As for summaries, no, there is no way, as that would be nonsensical (don’t 
> like the summary? just don’t ask for it - but there’s no meaning to getting 
> the summary of a value once you disabled its summary)
> 
> Yes, this is about synthetic children.  Summaries are not a problem.
>  
> 
>> I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(), 
>> but the former seems to always return false, and the latter gives me the 
>> same list of children as the original value.
> 
> Do you have a reproduction case I can look at?
> 
> My setup is kinda complicated, I want to make sure I am using the API 
> correctly before attempting to create a self-contained repro case.
>  

That’s fair. Can you at least try to describe what you’re trying to do and the 
data types involved in this?

> GetNonSyntheticValue() returning self is correct behavior if IsSynthetic() == 
> False; but if there really is a synthetic provider attached to the object, 
> IsSynthetic() should definitely return True
> 
> 
> Whose IsSynthetic() is supposed to return True,- the parent's or the child's? 
>  

What do you mean with this?
The model is that you have an SBValue, and that SBValue could be backed by a 
synthetic value. If you want, you can LLDB not to prefer synthetic values - 
which changes the way the current SBValue works - or for the same backing 
variable, give you a non-synthetic SBValue, which is what 
GetNonSyntheticValue() does

Parent/child should have nothing to do with this, unless I am misunderstanding 
you

> And on which object should I be calling GetNonSyntheticValue()?  (I assume on 
> the parent?)
> 
> Vadim


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] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 4:04 PM, Vadim Chugunov  wrote:
> 
> 
> 
> On Mon, Jan 25, 2016 at 3:31 PM, Enrico Granata  > wrote:
> 
>> 
>> Whose IsSynthetic() is supposed to return True,- the parent's or the 
>> child's?  
> 
> What do you mean with this?
> The model is that you have an SBValue, and that SBValue could be backed by a 
> synthetic value. If you want, you can LLDB not to prefer synthetic values - 
> which changes the way the current SBValue works - or for the same backing 
> variable, give you a non-synthetic SBValue, which is what 
> GetNonSyntheticValue() does
> 
> Parent/child should have nothing to do with this, unless I am 
> misunderstanding you
> 
> I guess I am confused about what "synthetic" refers to.  Let's say I have an 
> SBValue representing std::vector and stl formatters are enabled.   As far as 
> I understand, that SBValue itself (the parent) would be considered "real", 
> but its children (the vector elements) would be "synthetic" (because they 
> were generated by formatter).
> 

In your scenario, the SBValue for the vector is synthetic; the SBValue 
instances for each of the vector elements are not synthetic (well, unless, they 
are themselves vectors or other things with synthetic providers)

Does that match what you’re seeing?

> Vadim


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] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 4:09 PM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> lldb-340.4.119 (OSX 10.11.3)
> 
> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra  > wrote:
> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> > Hi,
> > If I have an SBValue for an object whose type has a formatter enabled for
> > it, is there a way to detect this via the Python API, and if so, request an
> > "unmodified" view of the object?
> > I've experimented with value.IsSynthetic() and value.GetNonSyntheticValue(),
> > but the former seems to always return false, and the latter gives me the
> > same list of children as the original value.
> 
> This was a problem way back in June '15 and Enrico fixed it. Which
> version of LLDB are you using?
> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


I have a hard time recalling which fix that was, I can look up old logs
With that said, if the fix happened in June ’15, it’s unlikely to be in lldb-340

I would encourage you to use trunk LLDB and see if that works better in your 
use case

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] Selectively disabling value formatter

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 4:48 PM, Siva Chandra  wrote:
> 
> I think this one: 
> http://llvm.org/viewvc/llvm-project?view=revision&revision=240578 
> 
> 
> On Mon, Jan 25, 2016 at 4:34 PM, Enrico Granata  > wrote:
> 
>> On Jan 25, 2016, at 4:09 PM, Vadim Chugunov via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> lldb-340.4.119 (OSX 10.11.3)
>> 
>> On Mon, Jan 25, 2016 at 3:42 PM, Siva Chandra > > wrote:
>> On Mon, Jan 25, 2016 at 12:23 AM, Vadim Chugunov via lldb-dev
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> > Hi,
>> > If I have an SBValue for an object whose type has a formatter enabled for
>> > it, is there a way to detect this via the Python API, and if so, request an
>> > "unmodified" view of the object?
>> > I've experimented with value.IsSynthetic() and 
>> > value.GetNonSyntheticValue(),
>> > but the former seems to always return false, and the latter gives me the
>> > same list of children as the original value.
>> 
>> This was a problem way back in June '15 and Enrico fixed it. Which
>> version of LLDB are you using?
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> 
> I have a hard time recalling which fix that was, I can look up old logs
> With that said, if the fix happened in June ’15, it’s unlikely to be in 
> lldb-340
> 
> I would encourage you to use trunk LLDB and see if that works better in your 
> use case
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 

Yeah, I don’t think that that change made into lldb-340

That might be the root cause of Vadim’s issue. Thanks for pointing that out 
Siva.

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] something just toasted the test suite on OS X

[Enrico Granata via lldb-dev]

> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Not sure exactly what it is, but all the tests are failing due to some bad 
> assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
> 

Author: zturner
Date: Mon Jan 25 18:59:42 2016
New Revision: 258759

URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev 

Log:
Write the session log file in UTF-8.

Previously we were writing in the default encoding, which depends
on the operating system and is not guaranteed to be unicode aware.
On Python 3, this would lead to a situation where writing unicode
text to the log file generates an exception.  The fix here is to
write session logs using the proper encoding, which incidentally
fixes another test, so xfail is removed from that.

sounds like a likely culprit from what you’re saying

> I am not going to be able to look at details on that, but here's a link to 
> the log on the OS X builder:
> 

Do you want me to revert?

> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console 
> 
> 
> -- 
> -Todd
> ___
> 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] something just toasted the test suite on OS X

[Enrico Granata via lldb-dev]

Should be reverted in 258791.

Sent from my iPhone

> On Jan 25, 2016, at 8:54 PM, Zachary Turner  wrote:
> 
> sorry, yea I stuck around for a while after that patch waiting for emails, 
> but nothing came through.  Please revert in the meantime, I'll work on a fix 
> tomorrow.
> 
>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev 
>>  wrote:
>> I think I see what happened w/r/t why no emails when out when the build went 
>> heavy red.  (Well they went out internally, but not externally).  When I 
>> made the change on Friday to improve the workflow for the Green Dragon OS X 
>> builder and test output, I switched email over to the builder step, which 
>> doesn't know anything about who made which changes.  So it didn't know who 
>> to put on the blame list for the broken build.  Drats, I'll have to figure 
>> that out.
>> 
>> I'd really prefer to have all those stages happening in one build step to 
>> keep it clear what's going on.
>> 
>>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>>> Well our whole test suite just stopped running, so yes.
>>> 
 On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata  wrote:
 
> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Not sure exactly what it is, but all the tests are failing due to some 
> bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
 
 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759
 
 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.
 
 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where writing unicode
 text to the log file generates an exception.  The fix here is to
 write session logs using the proper encoding, which incidentally
 fixes another test, so xfail is removed from that.
 
 sounds like a likely culprit from what you’re saying
 
> I am not going to be able to look at details on that, but here's a link 
> to the log on the OS X builder:
 
 Do you want me to revert?
 
> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
 
 
 Thanks,
 - Enrico
 📩 egranata@.com ☎️ 27683
>>> 
>>> 
>>> 
>>> -- 
>>> -Todd
>> 
>> 
>> 
>> -- 
>> -Todd
>> ___
>> 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] [Bug 27020] New: "command alias r run" causes an assert

[Enrico Granata via lldb-dev]

> On Mar 21, 2016, at 2:27 PM, via lldb-dev  wrote:
> 
> Bug ID27020 
> Summary   "command alias r run" causes an assert   
> Product   lldb
> Version   unspecified
> Hardware  PC
> OSWindows NT
> StatusNEW
> Severity  normal
> Priority  P
> Component All Bugs
> Assignee  lldb-dev@lists.llvm.org
> Reporter  ted.woodw...@codeaurora.org
> CCllvm-b...@lists.llvm.org
> ClassificationUnclassified
> 
> This happens on Linux and Windows; probably all platforms.
> 
> >bin/lldb /bin/ls
> (lldb) target create "/bin/ls"
> Current executable set to '/bin/ls' (x86_64).
> (lldb) command alias r run
> warning: Overwriting existing definition for 'r'.
> (lldb) r
> CommandAlias::Execute is not to be called
> UNREACHABLE executed at
> /local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
> Abort (core dumped)
> 
> 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

Ted,
unfortunately I am more than a little busy at the moment - and it would 
probably be a day or two before I can actually take a meaningful look at this

On the other hand, I suspect I know what the issue you’re running into is

Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
function that is responsible for taking an alias apart and passing the pieces 
to the command interpreter for actual execution.
In your case, what is happening is that you have an alias to an alias, so the 
underlying command is actually an alias

What one would need to try and do is write a recursive function that, given an 
alias, potentially nested, spits out the final OptionArgVectorSP and non-alias 
CommandObject
It is something I can work on, but as I said, it’s going to be a few days 
before I can get to it. So, if you want to try your hand at a patch to this 
effect, I would be most happy to take a look at it

Apologies for the breakage and thanks for reporting this

- Enrico

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

Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert

[Enrico Granata via lldb-dev]

Ted,
I think this is fixed by r264096

Can you try and make sure it works for you?

> On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev 
>  wrote:
> 
> 
>> On Mar 21, 2016, at 2:27 PM, via lldb-dev > <mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Bug ID   27020 <https://llvm.org/bugs/show_bug.cgi?id=27020>
>> Summary  "command alias r run" causes an assert   
>> Product  lldb
>> Version  unspecified
>> Hardware PC
>> OS   Windows NT
>> Status   NEW
>> Severity normal
>> Priority P
>> ComponentAll Bugs
>> Assignee lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> Reporter ted.woodw...@codeaurora.org <mailto:ted.woodw...@codeaurora.org>
>> CC   llvm-b...@lists.llvm.org <mailto:llvm-b...@lists.llvm.org>
>> Classification   Unclassified
>> 
>> This happens on Linux and Windows; probably all platforms.
>> 
>> >bin/lldb /bin/ls
>> (lldb) target create "/bin/ls"
>> Current executable set to '/bin/ls' (x86_64).
>> (lldb) command alias r run
>> warning: Overwriting existing definition for 'r'.
>> (lldb) r
>> CommandAlias::Execute is not to be called
>> UNREACHABLE executed at
>> /local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
>> Abort (core dumped)
>> 
>> You are receiving this mail because:
>> You are the assignee for the bug.
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> Ted,
> unfortunately I am more than a little busy at the moment - and it would 
> probably be a day or two before I can actually take a meaningful look at this
> 
> On the other hand, I suspect I know what the issue you’re running into is
> 
> Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
> executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
> function that is responsible for taking an alias apart and passing the pieces 
> to the command interpreter for actual execution.
> In your case, what is happening is that you have an alias to an alias, so the 
> underlying command is actually an alias
> 
> What one would need to try and do is write a recursive function that, given 
> an alias, potentially nested, spits out the final OptionArgVectorSP and 
> non-alias CommandObject
> It is something I can work on, but as I said, it’s going to be a few days 
> before I can get to it. So, if you want to try your hand at a patch to this 
> effect, I would be most happy to take a look at it
> 
> Apologies for the breakage and thanks for reporting this
> 
> - Enrico
> 
> ___
> 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] [Bug 27020] New: "command alias r run" causes an assert

[Enrico Granata via lldb-dev]

> On Mar 22, 2016, at 3:26 PM, Ted Woodward  wrote:
> 
> The assert is gone – the alias to an alias behaves as expected.

Glad to hear! I put in a test case just to make sure we don’t regress on this 
in the future

>  
> There is one issue with my testcase, “command alias r run”. That’s “help r”. 
> The last line is “'r' is an abbreviation for 'run -c /bin/sh --'”, but that’s 
> not true. ‘run’ is an abbreviation for 'process launch -c /bin/sh --', and r 
> is an abbreviation for ‘run’. From that help you’d infer that ‘r’ was an 
> abbreviation for ‘process launch –c /bin/sh -- -c /bin/sh’.
>  

I am not seeing that one - for me it just says 'r' is an abbreviation for ‘run'
With that said, I did make another patch following the one that fixes your issue
I’ll keep an eye out for this kind of issue!

> Thanks for the quick fix!

You’re welcome!
And obviously thanks to you for finding these issues out!

>  
> Ted
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: egran...@apple.com [mailto:egran...@apple.com] 
> Sent: Tuesday, March 22, 2016 4:14 PM
> To: Ted Woodward 
> Cc: LLDB 
> Subject: Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an 
> assert
>  
> Ted,
> I think this is fixed by r264096
>  
> Can you try and make sure it works for you?
>  
>> On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>  
>>  
>>> On Mar 21, 2016, at 2:27 PM, via lldb-dev >> <mailto:lldb-dev@lists.llvm.org>> wrote:
>>>  
>>> Bug ID
>>> 27020 <https://llvm.org/bugs/show_bug.cgi?id=27020>
>>> Summary
>>> "command alias r run" causes an assert 
>>> Product
>>> lldb 
>>> Version
>>> unspecified 
>>> Hardware
>>> PC 
>>> OS
>>> Windows NT 
>>> Status
>>> NEW 
>>> Severity
>>> normal 
>>> Priority
>>> P 
>>> Component
>>> All Bugs 
>>> Assignee
>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> Reporter
>>> ted.woodw...@codeaurora.org <mailto:ted.woodw...@codeaurora.org>
>>> CC
>>> llvm-b...@lists.llvm.org <mailto:llvm-b...@lists.llvm.org>
>>> Classification
>>> Unclassified 
>>>  
>>> This happens on Linux and Windows; probably all platforms.
>>>  
>>> >bin/lldb /bin/ls
>>> (lldb) target create "/bin/ls"
>>> Current executable set to '/bin/ls' (x86_64).
>>> (lldb) command alias r run
>>> warning: Overwriting existing definition for 'r'.
>>> (lldb) r
>>> CommandAlias::Execute is not to be called
>>> UNREACHABLE executed at
>>> /local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
>>> Abort (core dumped)
>>>  
>>> You are receiving this mail because: 
>>> You are the assignee for the bug.
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>  
>> Ted,
>> unfortunately I am more than a little busy at the moment - and it would 
>> probably be a day or two before I can actually take a meaningful look at this
>>  
>> On the other hand, I suspect I know what the issue you’re running into is
>>  
>> Due to existing complexity in the interpreter, a CommandAlias isn’t directly 
>> executable. So, we have CommandInterpreter::BuildAliasResult() which is the 
>> function that is responsible for taking an alias apart and passing the 
>> pieces to the command interpreter for actual execution.
>> In your case, what is happening is that you have an alias to an alias, so 
>> the underlying command is actually an alias
>>  
>> What one would need to try and do is write a recursive function that, given 
>> an alias, potentially nested, spits out the final OptionArgVectorSP and 
>> non-alias CommandObject
>> It is something I can work on, but as I said, it’s going to be a few days 
>> before I can get to it. So, if you want to try your hand at a patch to this 
>> effect, I would be most happy to take a look at it
>>  
>> Apologies for the breakage and thanks for reporting this
>>  
>> - Enrico
>>  
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>  
> 
> Thanks,
> - Enrico
> 📩 egranata@.com <mailto:egranata@> ☎️ 27683


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

[Enrico Granata via lldb-dev]

This is kind of orthogonal to your problem, but the reason why you are not 
seeing the kind of simplified printing Greg is suggesting, is because your 
std::string doesn’t look like any of the kinds we recognize

Specifically, LLDB data formatters work by matching against type names, and 
once they recognize a typename, then they try to inspect the variable in order 
to grab a summary
In your example, your std::string exposes a layout that we are not handling - 
hence we bail out of the formatter and we fall back to the raw view

If you want pretty printing to work, you’ll need to write a data formatter

There are a few avenues. The obvious easy one is to extend the existing 
std::string formatter to recognize your type’s internal layout.
If one were signing up for more infrastructure work, they could decide to try 
and detect shared library loads and load formatters that match with whatever 
libraries are being loaded.

> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev 
>  wrote:
> 
> So you need to be prepared to escape any text that can have special 
> characters. A "std::string" or any container can contain special characters. 
> If you are encoding stuff into JSON, you will either need to escape any 
> special characters, or hex encode the string into ASCII hex bytes. 
> 
> In debuggers we often get bogus data because variables are not initialized, 
> but the compiler tells us that a variable is valid in address range 
> [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a variable in 
> this case, a std::string might contain bogus data and the bytes might not 
> make sense. So you always have to be prepared for bad data.
> 
> If we look at:
> 
>  store_ = {
> = {
>  small_ = "www"
>  ml_ = (data_ =
> "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b",
> size_ = 0, capacity_ = 1441151880758558720)
>}
>  }
> }
> 
> We can see the "size_" is zero, and capacity_ is 1441151880758558720 (which 
> is 0x1400). "data_" seems to be some random pointer. 
> 
> On MacOSX, we have a special formatting code that displays std::string in 
> CPlusPlusLanguage.cpp that gets installed in the LoadLibCxxFormatters() or 
> LoadLibStdcppFormatters() functions with code like:
> 
>lldb::TypeSummaryImplSP std_string_summary_sp(new 
> CXXFunctionSummaryFormat(stl_summary_flags, 
> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary 
> provider"));
>
> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>  std_string_summary_sp);
> 
> Special flags are set on std::string to say "don't show children of this and 
> just show a summary" So if a std::string contained "hello". So for the 
> following code:
> 
> std::string h ("hello");
> 
> You should just see:
> 
> (lldb) fr var h
> (std::__1::string) h = "hello"
> 
> If you take a look at the normal value in the raw we see:
> 
> (lldb) fr var --raw h
> (std::__1::string) h = {
>  __r_ = {
>std::__1::__libcpp_compressed_pair_imp std::__1::char_traits, std::__1::allocator >::__rep, 
> std::__1::allocator, 2> = {
>  __first_ = {
> = {
>  __l = {
>__cap_ = 122511465736202
>__size_ = 0
>__data_ = 0x
>  }
>  __s = {
> = {
>  __size_ = '\n'
>  __lx = '\n'
>}
>__data_ = {
>  [0] = 'h'
>  [1] = 'e'
>  [2] = 'l'
>  [3] = 'l'
>  [4] = 'o'
>  [5] = '\0'
>  [6] = '\0'
>  [7] = '\0'
>  [8] = '\0'
>  [9] = '\0'
>  [10] = '\0'
>  [11] = '\0'
>  [12] = '\0'
>  [13] = '\0'
>  [14] = '\0'
>  [15] = '\0'
>  [16] = '\0'
>  [17] = '\0'
>  [18] = '\0'
>  [19] = '\0'
>  [20] = '\0'
>  [21] = '\0'
>  [22] = '\0'
>}
>  }
>  __r = {
>__words = {
>  [0] = 122511465736202
>  [1] = 0
>  [2] = 0
>}
>  }
>}
>  }
>}
>  }
> }
> 
> So the main question is why are our "std::string" formatters not kicking in 
> for you. That comes down to a typename match, or the format of the string 
> isn't what the formatter is expecting.
> 
> But again, since you std::string can contain anything, you will need to 
> escape any and all text that is encoded into JSON to ensure it doesn't 
> contain anything JSON can't deal with.
> 
>> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev 
>>  wrote:
>> 
>> Thanks Siva. All the DW_TAG_member related errors seems to go away after 
>> patching with your fix. The current problem is handling the decoding. 
>> 
>> Here is the correct decoding from gdb whic mi

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

[Enrico Granata via lldb-dev]

> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan  wrote:
> 
> Hi Enrico,
> 
> Any suggestion/example how to add a data formatter for our own STL string? 
> From the output below I can see we are using our own "fbstring_core" which I 
> assume I need to write a type summary for this type:
> 
> frame variable corpus -T
> (const string &const) corpus = error: summary string parsing error: {
>   (std::fbstring_core) store_ = {
> (std::fbstring_core::(anonymous union))  = {
>   (char [24]) small_ = "www"
>   (std::fbstring_core::MediumLarge) ml_ = {
> (char *) data_ = 0x0077 
> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89�����L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
> (std::size_t) size_ = 0
> (std::size_t) capacity_ = 1441151880758558720
>   }
> }
>   }
> }
> 

Admittedly, this is going to be a little vague since I haven’t really seen your 
code and I am only working off of one sample

There’s going to be two parts to getting this to work:

Part 1 - Formatting fbstring_core

At a glance, an fbstring_core can be backed by two representations. A 
“small” representation (a char array), and a “medium/large" representation (a 
char* + a size)
I assume that the way you tell one from the other is

if (size == 0) small
else medium-large

If my assumption is not correct, you’ll need to discover what the correct 
discriminator logic is - the class has to know, and so do you :-)

Armed with that knowledge, look in lldb 
source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp
There’s a bunch of code that deals with formatting llvm’s libc++ std::string - 
which follows a very similar logic to your class

ExtractLibcxxStringInfo() is the function that handles discovering which layout 
the string uses - where the data lives - and how much data there is

Once you have told yourself how much data there is (the size) and where it 
lives (array or pointer), LibcxxStringSummaryProvider() has the easy task - it 
sets up a StringPrinter, tells it how much data to print, where to get it from, 
and then delegates the StringPrinter to do the grunt work
StringPrinter is a nifty little tool - it can handle generating summaries for 
different kinds of strings (UTF8? UTF16? we got it - is a \0 a terminator? what 
quote character would you like? …) - you point it at some data, set up a few 
options, and it will generate a printable representation for you - if your 
string type is doing anything out of the ordinary, let’s talk - I am definitely 
open to extending StringPrinter to handle even more magic

Part 2 - Teaching std::string that it can be backed by an fbstring_core

At the end of part 1, you’ll probably end up with a 
FBStringCoreSummaryProvider() - now you need to teach LLDB about it
The obvious thing you could do would be to go in 
CPlusPlusLanguage::GetFormatters() add a LoadFBStringFormatter(g_category) to 
it - and then imitate - say - LoadLibCxxFormatters()

AddCXXSummary(cpp_category_sp, 
lldb_private::formatters::FBStringCoreSummaryProvider, “fbstringcore summary 
provider", ConstString(“std::fbstring_core<.+>"), stl_summary_flags, true);

That will work - but what you would see is:

> (const string &const) corpus = error: summary string parsing error: {
>   (std::fbstring_core) store_ = “www"

You wanna do

(lldb) log enable lldb formatters
(lldb) frame variable -T corpus

It will list one or more typenames - the most specific one is the one you like 
(e.g. for libc++ we get std::__1::string - this is how we tell ourselves this 
is the std::string from libc++)
Once you find that typename, you’ll make a new formatter - 
FBStringSummaryProvider() - and register that formatter with that very specific 
typename

All that FBStringSummaryProvider() has to do is get the “store_” member 
(ValueObject::GetChildMemberWithName() is your friend) - and pass it down to 
FBStringCoreSummaryProvider()


I understand this may seem a little convoluted and arcane at first - but feel 
free to ask more questions, and I’ll try to help out!

> Thanks.
> Jeffrey
> 
> On Mon, Mar 28, 2016 at 11:38 AM, Enrico Granata  > wrote:
> This is kind of orthogonal to your problem, but the reason why you are not 
> seeing the kind of simplified printing Greg is suggesting, is because your 
> std::string doesn’t look like any of the kinds we recognize
> 
> Specifically, LLDB data formatters work by matching against type names, and 
> once they recognize a typename, then they try to inspect the variable in 
> order to grab a summary
> In your example, your std::string exposes a layout that we are not handling - 
> hence we bail out of the formatter and we fall back to the raw view
> 
> If you want pretty printing to work, you’ll need to write a data formatter
> 
> There are a few avenues. The obvious easy one is to extend the existing 
> std::string formatter to recognize your type’s internal layout.
> If one 

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

[Enrico Granata via lldb-dev]

> On Apr 7, 2016, at 9:51 AM, Jim Ingham  wrote:
> 
> I don't think Enrico was suggesting that we maintain a bunch of third party 
> data formatters in the lldb source base.  

That depends - if this std::string implementation is part of a publicly 
available STL implementation, it might make sense for us to “know about it” out 
of the box in the same way we know about libstdc++ and libc++
If it is an internal-only string class, then, yes, I would definitely not 
suggest putting this inside the LLDB core

> He was giving C++ examples (using the lldb_private API's) because the STL 
> formatters are in C++, so that's what he had on hand to demonstrate the kinds 
> of algorithms you would use to dig into these complex structures.  For the 
> most part the lldb_private API's used in Enrico's examples are mirrored in 
> the SB API's pretty directly, so this isn't a terrible source for examples.
> 
> Note, it used to be possible to write C++ based data formatters, build them 
> in a shared library and load them with the "plugin load" command.  These have 
> the advantage of working on systems that don't support Python.  Not sure what 
> the state of that is these days, however.

It might or might not work. If it didn’t work and somebody wanted to fix that, 
I suspect we would gladly accept their patches.

>  But even if you were going to write C++ formatters you'd be better off using 
> the SB API's not the lldb_private API's since then your plugins would have a 
> longer useful life-cycle.
> 
> Jim
> 
> 
>> On Apr 7, 2016, at 2:45 AM, Tamas Berghammer via lldb-dev 
>>  wrote:
>> 
>> LLDB supports adding data formatters without modifying the source code and I 
>> would strongly prefer to go that way as we don't want each user of LLDB to 
>> start adding data formatters to their own custom types. We have a pretty 
>> detailed (but possible a bit outdated) description about how they work and 
>> how you can add a new one here: http://lldb.llvm.org/varformats.html
>> 
>> Enrico: Is there any reason you suggested the data formatters written inside 
>> LLDB over the python based ones?
>> 
>> On Thu, Apr 7, 2016 at 3:31 AM Jeffrey Tan via lldb-dev 
>>  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? 
>> 
>> Jeffrey
>> 
>> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata  wrote:
>> 
>>> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan  wrote:
>>> 
>>> Hi Enrico,
>>> 
>>> Any suggestion/example how to add a data formatter for our own STL string? 
>>> From the output below I can see we are using our own "fbstring_core" which 
>>> I assume I need to write a type summary for this type:
>>> 
>>> frame variable corpus -T
>>> (const string &const) corpus = error: summary string parsing error: {
>>>  (std::fbstring_core) store_ = {
>>>(std::fbstring_core::(anonymous union))  = {
>>>  (char [24]) small_ = "www"
>>>  (std::fbstring_core::MediumLarge) ml_ = {
>>>(char *) data_ = 0x0077 
>>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89���
>>>  ��L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
>>>(std::size_t) size_ = 0
>>>(std::size_t) capacity_ = 1441151880758558720
>>>  }
>>>}
>>>  }
>>> }
>>> 
>> 
>> Admittedly, this is going to be a little vague since I haven’t really seen 
>> your code and I am only working off of one sample
>> 
>> There’s going to be two parts to getting this to work:
>> 
>> Part 1 - Formatting fbstring_core
>> 
>> At a glance, an fbstring_core can be backed by two representations. A 
>> “small” representation (a char array), and a “medium/large" representation 
>> (a char* + a size)
>> I assume that the way you tell one from the other is
>> 
>> if (size == 0) small
>> else medium-large
>> 
>> If my assumption is not correct, you’ll need to discover what the correct 
>> discriminator logic is - the class has to know, and so do you :-)
>> 
>> Armed with that knowledge, look in lldb 
>> source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp
>> There’s a bunch of code that deals with formatting llvm’s libc++ std::string 
>> - which follows a very similar logic to your class
>> 
>> ExtractLibcxxStringInfo() is the function that handles discovering which 
>> layout the string uses - where the data lives - and how much data there is
>> 
>> Once you have told yourself how much data there is (the size) and where it 
>> lives (array or pointer), LibcxxStringSummaryProvider() has the easy task - 
>> it 

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

[Enrico Granata via lldb-dev]

> 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 modifying the debugger core

> Jeffrey
> 
> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata  > wrote:
> 
>> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan > > wrote:
>> 
>> Hi Enrico,
>> 
>> Any suggestion/example how to add a data formatter for our own STL string? 
>> From the output below I can see we are using our own "fbstring_core" which I 
>> assume I need to write a type summary for this type:
>> 
>> frame variable corpus -T
>> (const string &const) corpus = error: summary string parsing error: {
>>   (std::fbstring_core) store_ = {
>> (std::fbstring_core::(anonymous union))  = {
>>   (char [24]) small_ = "www"
>>   (std::fbstring_core::MediumLarge) ml_ = {
>> (char *) data_ = 0x0077 
>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89���
>>  ��L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
>> (std::size_t) size_ = 0
>> (std::size_t) capacity_ = 1441151880758558720
>>   }
>> }
>>   }
>> }
>> 
> 
> Admittedly, this is going to be a little vague since I haven’t really seen 
> your code and I am only working off of one sample
> 
> There’s going to be two parts to getting this to work:
> 
> Part 1 - Formatting fbstring_core
> 
> At a glance, an fbstring_core can be backed by two representations. A 
> “small” representation (a char array), and a “medium/large" representation (a 
> char* + a size)
> I assume that the way you tell one from the other is
> 
> if (size == 0) small
> else medium-large
> 
> If my assumption is not correct, you’ll need to discover what the correct 
> discriminator logic is - the class has to know, and so do you :-)
> 
> Armed with that knowledge, look in lldb 
> source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp
> There’s a bunch of code that deals with formatting llvm’s libc++ std::string 
> - which follows a very similar logic to your class
> 
> ExtractLibcxxStringInfo() is the function that handles discovering which 
> layout the string uses - where the data lives - and how much data there is
> 
> Once you have told yourself how much data there is (the size) and where it 
> lives (array or pointer), LibcxxStringSummaryProvider() has the easy task - 
> it sets up a StringPrinter, tells it how much data to print, where to get it 
> from, and then delegates the StringPrinter to do the grunt work
> StringPrinter is a nifty little tool - it can handle generating summaries for 
> different kinds of strings (UTF8? UTF16? we got it - is a \0 a terminator? 
> what quote character would you like? …) - you point it at some data, set up a 
> few options, and it will generate a printable representation for you - if 
> your string type is doing anything out of the ordinary, let’s talk - I am 
> definitely open to extending StringPrinter to handle even more magic
> 
> Part 2 - Teaching std::string that it can be backed by an fbstring_core
> 
> At the end of part 1, you’ll probably end up with a 
> FBStringCoreSummaryProvider() - now you need to teac

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

[Enrico Granata via lldb-dev]

> On Apr 13, 2016, at 10:11 AM, Jeffrey Tan  wrote:
> 
> One quick question: do we support getting type summary string from inferior 
> method call?

No - for that you are going to need to write a Python formatter.

Running code in formatters is a risky endeavor for a bunch of reasons, so it is 
by design that it is not an easily accessible building block

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

Because, as you say, it has a high risk of side effects
Also, it is less efficient than direct memory reads (I have a comparison graph 
somewhere where some data formatter became an order of magnitude faster once it 
stopped running code)
Also, what happens when your object is in scope but not yet initialized, or 
you’re stopped in its destructor and it’s partially torn down? Are you going to 
make all your methods able to deal safely with states that should never happen 
in production because you might actually run into them in the debugger?

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

The model you’re describing is similar to the “po” model we have in ObjC and 
Swift. Those languages provide a sanctioned language-blessed way to create an 
object description in program code (see -description for ObjC, and the whole 
Mirror story for Swift)
Those are OK because they are only triggered by explicit user action (running 
the “po” command in the debugger), and yet we still occasionally see problems 
with them where the user didn’t realize the program state was corrupt enough 
that running code there was a bad idea

C++ has no such sanctioned mechanism to generate descriptions - if one came 
about, LLDB would support it, in the form of making “po” do the right thing for 
C++ objects

> 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 modifying the debugger core
>> 
>>> Jeffrey
>>> 
 On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata  wrote:
 
> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan  wrote:
> 
> Hi Enrico,
> 
> Any suggestion/example how to add a data formatter for our own STL 
> string? From the output below I can see we are using our own 
> "fbstring_core" which I assume I need to write a type summary for this 
> type:
> 
> frame variable corpus -T
> (const string &const) corpus = error: summary string parsing error: {
>   (std::fbstring_core) store_ = {
> (std::fbstring_core::(anonymous union))  = {
>   (char [24]) small_ = "www"
>   (std::fbstring_co

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

[Enrico Granata via lldb-dev]

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 modifying the debugger 
>>> core
>>> 
 Jeffrey
 
> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata  
> wrote:
> 
>> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan  wrote:
>> 
>> Hi Enrico,
>> 
>> Any suggestion/example how to add a data formatter for our own STL 
>> string? From the output below I can see we are using our own 
>> "fbstring_core" which I assume I need to write a type summary for this 
>> type:
>> 
>> frame variable corpus -T
>> (const string &const) corpus = error: summary string parsing error: {
>>   (std::fbstring_core) store_ = {
>> (std::fbstring_core::(anonymous union))  = {
>>   (char [24]) small_ = "www"
>>   (std::fbstring_core::MediumLarge) ml_ = {
>> (char *) data_ = 0x0077 
>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H

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

[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] lldb type summary provider - SBProcess is invalid

[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] LLDB Evolution - Final Form

[Enrico Granata via lldb-dev]

A few remarks

> On Sep 19, 2016, at 1:18 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Following up with Kate's post from a few weeks ago, I think the dust has 
> settled on the code reformat and it went over pretty smoothly for the most 
> part.  So I thought it might be worth throwing out some ideas for where we go 
> from here.  I have a large list of ideas (more ideas than time, sadly) that 
> I've been collecting over the past few weeks, so I figured I would throw them 
> out in the open for discussion.
> 
> I’ve grouped the areas for improvement into 3 high level categories.
> 
> De-inventing the wheel - We should use more code from LLVM, and delete code 
> in LLDB where LLVM provides a solution.  In cases where there is an LLVM 
> thing that is *similar* to what we need, we should extend the LLVM thing to 
> support what we need, and then use it.  Following are some areas I've 
> identified.  This list is by no means complete.  For each one, I've given a 
> personal assessment of how likely it is to cause some (temporary) hiccups, 
> how much it would help us in the long run, and how difficult it would be to 
> do.  Without further ado:
> Use llvm::Regex instead of lldb::Regex
> llvm::Regex doesn’t support enhanced mode.  Could we add support for this to 
> llvm::Regex?
> Risk: 6
> Impact: 3
> Difficulty / Effort: 3  (5 if we have to add enhanced mode support)
> Use llvm streams instead of lldb::StreamString
> Supports output re-targeting (stderr, stdout, std::string, etc), printf style 
> formatting, and type-safe streaming operators.
> Interoperates nicely with many existing llvm utility classes
> Risk: 4
> Impact: 5
> Difficulty / Effort: 7
> Use llvm::Error instead of lldb::Error
> llvm::Error is an error class that *requires* you to check whether it 
> succeeded or it will assert.

I assume that assertion would be stripped in Release builds?
We have our own lldbassert() macro currently, which assert()s in Debug mode, 
but in Release mode produces an error message and continues
It would be great if llvm::Error allowed us to plug that in..

>   In a way, it's similar to a C++ exception, except that it doesn't come with 
> the performance hit associated with exceptions.  It's extensible, and can be 
> easily extended to support the various ways LLDB needs to construct errors 
> and error messages.
> Would need to first rename lldb::Error to LLDBError so that te conversion 
> from LLDBError to llvm::Error could be done incrementally.
> Risk: 7
> Impact: 7
> Difficulty / Effort: 8
> StringRef instead of const char *, len everywhere
> Can do most common string operations in a way that is guaranteed to be safe.
> Reduces string manipulation algorithm complexity by an order of magnitude.
> Can potentially eliminate tens of thousands of string copies across the 
> codebase.
> Simplifies code.
> Risk: 3
> Impact: 8
> Difficulty / Effort: 7
> ArrayRef instead of const void *, len everywhere
> Same analysis as StringRef
> MutableArrayRef instead of void *, len everywhere
> Same analysis as StringRef

I don't think we have a lot of those - IIRC, it's mostly in the SB API where 
SWIG is supposed to map it back to a Python string

> Delete ConstString, use a modified StringPool that is thread-safe.
> StringPool is a non thread-safe version of ConstString.
> Strings are internally refcounted so they can be cleaned up when they are no 
> longer used.  ConstStrings are a large source of memory in LLDB, so 
> ref-counting and removing stale strings has the potential to be a huge 
> savings.
> Risk: 2
> Impact: 9
> Difficulty / Effort: 6
> thread_local instead of lldb::ThreadLocal
> This fixes a number of bugs on Windows that cannot be fixed otherwise, as 
> they require compiler support.
> Some other compilers may not support this yet?
> Risk: 2
> Impact: 3
> Difficulty: 3
> Use llvm::cl for the command line arguments to the primary lldb executable.
> Risk: 2
> Impact: 3
> Difficulty / Effort: 4
> Testing - Our testing infrastructure is unstable, and our test coverage is 
> lacking.  We should take steps to improve this.
> Port as much as possible to lit
> Simple tests should be trivial to port to lit today.  If nothing else this 
> serves as a proof of concept while increasing the speed and stability of the 
> test suite, since lit is a more stable harness.
> Separate testing tools
> One question that remains open is how to represent the complicated needs of a 
> debugger in lit tests.  Part a) above covers the trivial cases, but what 
> about the difficult cases?  In https://reviews.llvm.org/D24591 
>  a number of ideas were discussed.  We 
> started getting to this idea towards the end, about a separate tool which has 
> an interface independent of the command line interface and which can be used 
> to test.  lldb-mi was mentioned.  While I have serious concerns about lldb-mi 
> due to its poorly written and tested codebase, I do agree in principle with 
> the methodology.  

Re: [lldb-dev] LLDB Evolution - Final Form

[Enrico Granata via lldb-dev]

> On Sep 19, 2016, at 2:31 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> 
> 
> On Mon, Sep 19, 2016 at 2:20 PM Mehdi Amini  > wrote:
> 
> 
> I’m surprise by your aversion to assertions, what is your suggested 
> alternative? Are you expecting to check and handle every possible invariants 
> everywhere and recover (or signal an error) properly? That does not seem 
> practical, and it seems to me that it'd lead to just involving UB (or 
> breaking design invariant) without actually noticing it.
> 
> > Also many asserts are in header files so even if you build llvm and clang 
> > with asserts off, but then build our project that uses LLVM with asserts 
> > on, you get LLVM and clang asserts when you don't want them.
> 
> It is not really supported to use the LLVM C++ headers without assertions and 
> link to a LLVM build with assertions (and vice-versa).
>  
> It seems to me that you are mixing two things: asserting on user inputs vs 
> asserting on internal invariants of the system. LLVM is very intensive about 
> asserting on the second category and this seems fine to me.
> Asserting on external inputs is not great (in LLVM as much as in LLDB).
> 
> The asserting error class above falls into the second category and is a great 
> tool to enforce programmer error
> 
> 
> I can kind of see both sides on this one.  Yes, if you can catch instances of 
> UB before it happens that's helpful.  At the same time, when you've got a 
> product (such as, say, Xcode), you also want to try as hard as possible not 
> to bring the whole product down.  In lldb we have lldbassert, which asserts 
> for real in debug, but in release it logs an error to a file.  This is nice 
> because if someone submits a crash report, we can see the assertion failure 
> in the log file.
> 
> Now, obviously the *real* solution is to make LLDB out-of-process so it 
> doesn't bring down Xcode when it crashes.  But (and I have no knowledge of 
> the Xcode / LLDB integration) I can easily see this being a monumental amount 
> of effort.
> 

Even then, IMO you are not out of the business of not crashing on people
Sure, now you didn't crash all of Xcode, but you still lost somebody's debug 
session with potentially valuable state in it...

It sounds like llvm::Expected + lldbassert() is a good combination; it makes 
sure we don't just drop error conditions on the ground, but it also makes sure 
that we don't just give up the ghost and crash..

> Personally, asserting in LLDB doesn't affect me and I'm fine with lldb::Error 
> asserting..  But I can kind of see the argument for not wanting it to assert. 
>  
> 
> On the other hand, if we had better test coverage, then all

I wonder if catching them all can't somehow be reduced to the halting problem 
:) Most would already be great!

> of these assertions would be caught during test anyway.  Which brings us back 
> to item #2 on my list...
> ___
> 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] RFC: Break/Watchpoint refactor

[Enrico Granata via lldb-dev]

> On Sep 27, 2016, at 1:09 PM, Daniel Austin Noland via lldb-dev 
>  wrote:
> 
> * Prefer explicitly deleted copy ctor / assignments over multiline macro 
> DISALLOW_COPY_AND_ASSIGN


Why not just move DISALLOW_COPY_AND_ASSIGN over to using =delete ? That seems 
like a trivial change..

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] Connecting to lldb-rpc-server

[Enrico Granata via lldb-dev]

I am gonna echo Kate's question, but delve one level deeper

Why do you want to send commands to LLDB from a different process?

We have a bunch of different extension points in LLDB, so it's possible that 
what you're trying to do is actually already possible

> On Oct 7, 2016, at 10:41 AM, Rex Fenley via lldb-dev 
>  wrote:
> 
> Hi Kate,
> 
> I'm trying to connect to the running instance of lldb in Xcode to send 
> commands to it from a different process :)
> 
> On Fri, Oct 7, 2016 at 10:27 AM, Kate Stone  > wrote:
> The RPC mechanism used in Xcode 8 is not a part of the open source LLDB 
> project and should be treated as an implementation detail of Xcode.  What are 
> you trying to accomplish?
> 
> Kate Stone k8st...@apple.com 
>  Xcode Low Level Tools
> 
>> On Oct 6, 2016, at 6:11 PM, Rex Fenley via lldb-dev > > wrote:
>> 
>> Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having trouble.
>> 
>> This doesn't seem to work to list the hosts.
>> rpcinfo -p lldb-rpc-server
>> 
>> Can't contact rpcbind on lldb-rpc-server
>> 
>> 
>> rpcinfo: RPC: Unknown host
>> 
>> Am I doing this correctly?
>> 
>> -- 
>> Rex Fenley  |  IOS DEVELOPER
>> 
>> 
>> Remind.com  |  BLOG   |  
>> FOLLOW US   |  LIKE US 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> 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] Connecting to lldb-rpc-server

[Enrico Granata via lldb-dev]

I can see a couple of avenues for your use case:

- you can write custom LLDB commands (obligatory reference: 
http://lldb.llvm.org/python-reference.html 
) and have your users type these 
via the console instead of by clicking buttons
- you could write a Python script that pops up extra UI and have your buttons 
run as part of LLDB that way. I have admittedly never tried to do this, and it 
might require some tinkering, but in theory I believe it should be possible

Personally, I'd rather much have console commands I can type instead of a magic 
separate UI that might even be hidden underneath other windows or hiding useful 
information unless I drag it out of the way, but then it's annoying to reach 
for when I need it, ..., but that's me...

> On Oct 7, 2016, at 11:27 AM, Rex Fenley  wrote:
> 
> I'm trying to build a separate debugging tool that can be used in unison with 
> Xcode it will provide buttons that are shortcuts to lldb scripts we write.
> 
> On Fri, Oct 7, 2016 at 10:45 AM, Enrico Granata  > wrote:
> I am gonna echo Kate's question, but delve one level deeper
> 
> Why do you want to send commands to LLDB from a different process?
> 
> We have a bunch of different extension points in LLDB, so it's possible that 
> what you're trying to do is actually already possible
> 
>> On Oct 7, 2016, at 10:41 AM, Rex Fenley via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi Kate,
>> 
>> I'm trying to connect to the running instance of lldb in Xcode to send 
>> commands to it from a different process :)
>> 
>> On Fri, Oct 7, 2016 at 10:27 AM, Kate Stone > > wrote:
>> The RPC mechanism used in Xcode 8 is not a part of the open source LLDB 
>> project and should be treated as an implementation detail of Xcode.  What 
>> are you trying to accomplish?
>> 
>> Kate Stone k8st...@apple.com 
>>  Xcode Low Level Tools
>> 
>>> On Oct 6, 2016, at 6:11 PM, Rex Fenley via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having trouble.
>>> 
>>> This doesn't seem to work to list the hosts.
>>> rpcinfo -p lldb-rpc-server
>>> 
>>> Can't contact rpcbind on lldb-rpc-server
>>> 
>>> 
>>> rpcinfo: RPC: Unknown host
>>> 
>>> Am I doing this correctly?
>>> 
>>> -- 
>>> Rex Fenley  |  IOS DEVELOPER
>>> 
>>> 
>>> Remind.com  |  BLOG   |  
>>> FOLLOW US   |  LIKE US 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> Rex Fenley  |  IOS DEVELOPER
>> 
>> 
>> Remind.com  |  BLOG   |  
>> FOLLOW US   |  LIKE US 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 

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] Connecting to lldb-rpc-server

[Enrico Granata via lldb-dev]

It is my understanding that this is not possible in the current architecture

> On Oct 7, 2016, at 11:55 AM, Rex Fenley  wrote:
> 
> We expect to have a rich user experience as this tool progresses, using 
> Python to generate UI will limit our development process. It would be much 
> simpler if we could communicate with Xcode's lldb directly from our 
> application.
> 
> On Fri, Oct 7, 2016 at 11:33 AM, Enrico Granata  > wrote:
> I can see a couple of avenues for your use case:
> 
> - you can write custom LLDB commands (obligatory reference: 
> http://lldb.llvm.org/python-reference.html 
> ) and have your users type these 
> via the console instead of by clicking buttons
> - you could write a Python script that pops up extra UI and have your buttons 
> run as part of LLDB that way. I have admittedly never tried to do this, and 
> it might require some tinkering, but in theory I believe it should be possible
> 
> Personally, I'd rather much have console commands I can type instead of a 
> magic separate UI that might even be hidden underneath other windows or 
> hiding useful information unless I drag it out of the way, but then it's 
> annoying to reach for when I need it, ..., but that's me...
> 
>> On Oct 7, 2016, at 11:27 AM, Rex Fenley > > wrote:
>> 
>> I'm trying to build a separate debugging tool that can be used in unison 
>> with Xcode it will provide buttons that are shortcuts to lldb scripts we 
>> write.
>> 
>> On Fri, Oct 7, 2016 at 10:45 AM, Enrico Granata > > wrote:
>> I am gonna echo Kate's question, but delve one level deeper
>> 
>> Why do you want to send commands to LLDB from a different process?
>> 
>> We have a bunch of different extension points in LLDB, so it's possible that 
>> what you're trying to do is actually already possible
>> 
>>> On Oct 7, 2016, at 10:41 AM, Rex Fenley via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> Hi Kate,
>>> 
>>> I'm trying to connect to the running instance of lldb in Xcode to send 
>>> commands to it from a different process :)
>>> 
>>> On Fri, Oct 7, 2016 at 10:27 AM, Kate Stone >> > wrote:
>>> The RPC mechanism used in Xcode 8 is not a part of the open source LLDB 
>>> project and should be treated as an implementation detail of Xcode.  What 
>>> are you trying to accomplish?
>>> 
>>> Kate Stone k8st...@apple.com 
>>>  Xcode Low Level Tools
>>> 
 On Oct 6, 2016, at 6:11 PM, Rex Fenley via lldb-dev 
 mailto:lldb-dev@lists.llvm.org>> wrote:
 
 Hi! I'm trying to connect to Xcode's lldb rpc server but I'm having 
 trouble.
 
 This doesn't seem to work to list the hosts.
 rpcinfo -p lldb-rpc-server
 
 Can't contact rpcbind on lldb-rpc-server
 
 
 rpcinfo: RPC: Unknown host
 
 Am I doing this correctly?
 
 -- 
 Rex Fenley  |  IOS DEVELOPER
 
 
 Remind.com  |  BLOG   |  
 FOLLOW US   |  LIKE US 
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org 
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Rex Fenley  |  IOS DEVELOPER
>>> 
>>> 
>>> Remind.com  |  BLOG   |  
>>> FOLLOW US   |  LIKE US 
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> 
>> 
>> Thanks,
>> - Enrico
>> 📩 egranata@.com ☎️ 27683
>> 
>> 
>> 
>> 
>> -- 
>> Rex Fenley  |  IOS DEVELOPER
>> 
>> 
>> Remind.com  |  BLOG   |  
>> FOLLOW US   |  LIKE US 
>> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 
> 
> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> 

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] LLDB support for python scripts in ELF section, like .debug_gdb_scripts in GDB

[Enrico Granata via lldb-dev]

LLDB has a similar feature, except:

a) it tries to load python scripts from dSYM bundles. If you have debug info 
stored in foo.dSYM, it will look for foo.dSYM/Contents/Resources/Python/foo.py
As far as I know, dSYMs only exist on Apple systems, so clearly you would need 
to design something else to load from places other than such debug info bundles

b) the feature is off by default, but there's a setting you can tweak to enable 
it. That is due to security concerns
I have given some thought to ideas in that space (e.g. code-signatures for the 
script files) but no code exists to back those thoughts

> On Oct 4, 2016, at 8:02 AM, Richard Geary via lldb-dev 
>  wrote:
> 
> Has LLDB considered adding per-binary support for LLDB python scripts,
> eg. for adding custom type summaries?
> 
> This is the equivalent GDB feature
> https://sourceware.org/gdb/onlinedocs/gdb/dotdebug_005fgdb_005fscripts-section.html
> 
> GDB can load a custom python script from either a side-installed file
> or an ELF section.  This allows debugging of multiple binaries with
> different implementations of the pretty-printer.
> 
> Any suggestions for LLDB workarounds would be welcome.
> ___
> 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

[lldb-dev] Code ownership resignation

[Enrico Granata via lldb-dev]

Hi,
as some of you likely already know I will be leaving Apple at the end of 
November


This career change also means I will not be as involved in lldb as I 
have been in the past. It also means I don't believe I would be doing 
the best interest of the community by serving as a code owner. For that 
reason, I'd like to resign from my code ownership duties.


As of today, I am code owner for:
D: Data Formatters, Core/Value*, Objective C Language runtime, Test 
suite, Xcode build

D: SWIG

I would recommend that the community consider Jim Ingham for taking over 
data formatters. He is already code owner for Objective-C runtime and 
ValueObject.


I'd like to recommend that the remaining part of Value* 
(Value.h/Value.cpp) go to Greg Clayton.


Zachary Turner has done a lot of great work on our test suite 
infrastructure, and I am confident that the community would be well 
served by having him serve as code owner for that portion of the project 
going forward.


I have no specific suggestions for the Xcode build and the SWIG bits. 
With that said, I would encourage the choice of somebody inside Apple 
given that Xcode is exclusive to the Mac, and the SWIG bits could 
certainly benefit from a code owner who is aware of the stringent 
requirements Apple has on SWIG versions.


Last, but not least, I'd like to say that working with the lldb - and 
broader llvm - community has been a great honor. This is a diverse, 
talented and passionate group of engineers with the common goal of 
producing high-quality software and the skills to deliver on that goal, 
time and again. While I won't be around as much in the future, I am 
confident that the project will continue to thrive and improve!


/- Enrico/


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

Re: [lldb-dev] Bug in CommandObjectFrameVariable::DoExecute()

[Enrico Granata via lldb-dev]

On 11/18/16 3:55 PM, Zachary Turner via lldb-dev wrote:

On line 708 of CommandObjectFrame.cpp, I'm looking at this code:

options.SetRootValueObjectName(name_cstr);

This code occurs inside the else block of an if/else.  name_cstr is 
declared prior to the if/else block and initialized to nullptr, but is 
only ever set to something other than nullptr in the if branch.


So, this code is equivalent to

options.SetRootValueObjectName(nullptr);

Is this intended,

Probably not
and if not how would this bug manifest itself in terms of incorrect 
behavior?
That I am not sure about.. I tried a couple obvious things, but I 
couldn't make them fail. It's possible that some arcane combination of 
options would do it. OTOH, my hunch is that we could simply fix the bug. 
Trying a patch of the form


Index: source/Commands/CommandObjectFrame.cpp
===
--- source/Commands/CommandObjectFrame.cpp(revision 287375)
+++ source/Commands/CommandObjectFrame.cpp(working copy)
@@ -704,7 +704,7 @@
   options.SetFormat(format);
   options.SetVariableFormatDisplayLanguage(
   valobj_sp->GetPreferredDisplayLanguage());
-  options.SetRootValueObjectName(name_cstr);
+  options.SetRootValueObjectName(var_sp ? 
var_sp->GetName().AsCString() : nullptr);

   valobj_sp->Dump(result.GetOutputStream(), options);
 }
   }

is the first thing I would do. On the face of it, it looks correct 
behavior (the "root name" is the name of the variable being displayed). 
Still worth a test suite run of course - but if you run into any 
regressions due to the change, it's worth bringing them up. It's 
possible the test is testing the wrong behavior and we found our smoking 
gun in terms of actual incorrect behavior.



___
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] How to deal with STL type names in C++ code?

[Enrico Granata via lldb-dev]

Hi Eugene,

> On Aug 6, 2015, at 2:02 PM, Eugene Birukov via lldb-dev 
>  wrote:
> 
> Hi,
> 
> I am using LLDB C++ API to create custom debugger and trying to dump 
> variables with their types. To do that I am using SBValue.GetTypeName() API. 
> Some types are OK, but some others - especially ones related to STL - are 
> quite unreadable:
> 

those type names are the actual fully-specialized STL type names. I am not sure 
how to control GDB to stop truncating your string formatting, but after the “…” 
there actually is more text
It looks like what you have is std::unique_ptr > > and 
those templates all take more arguments which are defaulted so you don’t have 
to type them in code - but are reflected in the type name

> (gdb) p value.GetTypeName()
> $1 = 0x7fffe419be40 
> "std::__1::unique_ptr std::__1::char_traits, std::__1::allocator >, 
> std::__1::allocator std::__1::char_traits (gdb) p value.GetDisplayTypeName()
> $2 = 0x7fffe419be40 
> "std::__1::unique_ptr std::__1::char_traits, std::__1::allocator >, 
> std::__1::allocator std::__1::char_traits (gdb) 
> 
> So, is there any way to convert them into some more human-friendly form?

Not currently. What one would have to do is hook into the C++ type printing 
logic such that it would know to leave out these extra template arguments when 
they have a default value

> 
> Thanks,
> Eugene
> ___
> 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] How to deal with STL type names in C++ code?

[Enrico Granata via lldb-dev]

> On Aug 6, 2015, at 3:33 PM, Siva Chandra  wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata  <mailto:egran...@apple.com>> wrote:
> To be honest, my favorite approach would be to modify clang’s TypePrinter to 
> do this, and then hooking up GetDisplayTypeName() to use whatever flags would 
> be necessary to invoke that bit of magic
> 
> Do you mean that clang's "pretty printer" should be made extensible by a 
> script?
>  

Nope, what I am imagining is not an extensible system

When LLDB goes to print a type it asks the compiler “what is the name of this 
type that I should display?”
By default, clang prints the fully specialized template, including type 
arguments that have their default value. My theory is that we would want to add 
a mode to the type printer to say “simplify type name”, and that would do 
sensible things to get a display name that is more compact

That seems more interesting than a set of regular expression heuristics on the 
type name, which is probably all you could do without specialized compiler-y 
knowledge of types

> 
>> On Aug 6, 2015, at 2:33 PM, Siva Chandra > <mailto:sivachan...@google.com>> wrote:
>> 
>> FWIW, GDB has a similar concept called type-printers:
>> https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html 
>> <https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html>
>> 
>> On Thu, Aug 6, 2015 at 2:24 PM, Siva Chandra > <mailto:sivachan...@google.com>> wrote:
>>> Hi Enrico,
>>> 
>>> I was thinking about the same issue today. Could we add a concept
>>> called "TypeNameModifier" and provide ability to define modifiers in
>>> scripts and command line? With this, a name like
>>> std::__1::basic_string<...> can be modified into a more friendly name
>>> like std::string? We could ofcourse have more complex modifications.
>>> 
>>> I think it is doable, but what is your (and the community's) opinion
>>> about adding such a feature? If you are OK, I would like to take up
>>> adding such a feature.
>>> 
>>> Thanks,
>>> Siva Chandra
>>> 
>>> On Thu, Aug 6, 2015 at 2:15 PM, Enrico Granata via lldb-dev
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>> Hi Eugene,
>>>> 
>>>> On Aug 6, 2015, at 2:02 PM, Eugene Birukov via lldb-dev
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I am using LLDB C++ API to create custom debugger and trying to dump
>>>> variables with their types. To do that I am using SBValue.GetTypeName() 
>>>> API.
>>>> Some types are OK, but some others - especially ones related to STL - are
>>>> quite unreadable:
>>>> 
>>>> 
>>>> those type names are the actual fully-specialized STL type names. I am not
>>>> sure how to control GDB to stop truncating your string formatting, but 
>>>> after
>>>> the “…” there actually is more text
>>>> It looks like what you have is std::unique_ptr > >
>>>> and those templates all take more arguments which are defaulted so you 
>>>> don’t
>>>> have to type them in code - but are reflected in the type name
>>>> 
>>>> (gdb) p value.GetTypeName()
>>>> $1 = 0x7fffe419be40
>>>> "std::__1::unique_ptr>>> std::__1::char_traits, std::__1::allocator >,
>>>> std::__1::allocator>>> std::__1::char_traits>>> (gdb) p value.GetDisplayTypeName()
>>>> $2 = 0x7fffe419be40
>>>> "std::__1::unique_ptr>>> std::__1::char_traits, std::__1::allocator >,
>>>> std::__1::allocator>>> std::__1::char_traits>>> (gdb)
>>>> 
>>>> 
>>>> So, is there any way to convert them into some more human-friendly form?
>>>> 
>>>> 
>>>> Not currently. What one would have to do is hook into the C++ type printing
>>>> logic such that it would know to leave out these extra template arguments
>>>> when they have a default value
>>>> 
>>>> 
>>>> Thanks,
>>>> Eugene
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>> 
>>>> 
>>>> 
>>>> Thanks,
>>>> - Enrico
>>>> 📩 egranata@.com ️ 27683
>>>> 
>>>> 
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>>>> 
> 
> 
> Thanks,
> - Enrico
> 📩 egranata@.com ☎️ 27683
> 
> 


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] How to deal with STL type names in C++ code?

[Enrico Granata via lldb-dev]

> On Aug 6, 2015, at 3:50 PM, Siva Chandra  wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 3:38 PM, Enrico Granata  <mailto:egran...@apple.com>> wrote:
> 
>> On Aug 6, 2015, at 3:33 PM, Siva Chandra > <mailto:sivachan...@google.com>> wrote:
>> 
>> 
>> 
>> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata > <mailto:egran...@apple.com>> wrote:
>> To be honest, my favorite approach would be to modify clang’s TypePrinter to 
>> do this, and then hooking up GetDisplayTypeName() to use whatever flags 
>> would be necessary to invoke that bit of magic
>> 
>> Do you mean that clang's "pretty printer" should be made extensible by a 
>> script?
>>  
> 
> Nope, what I am imagining is not an extensible system
> 
> When LLDB goes to print a type it asks the compiler “what is the name of this 
> type that I should display?”
> By default, clang prints the fully specialized template, including type 
> arguments that have their default value. My theory is that we would want to 
> add a mode to the type printer to say “simplify type name”, and that would do 
> sensible things to get a display name that is more compact
> 
> So, how would clang know about the "simplified" or "friendly" name for a 
> type? Even in case of standard library types, the underlying types (with 
> unfriendly type names) could be anything. For example, libstdc++ and STLport 
> have different underlying naming conventions. So does libc++ I would imagine 
> (I have not spent enough time yet staring at libc++ code).
> 

The obvious mechanism is that the compiler has knowledge of the structure of 
the type - so it can make printing decisions based on that type structure
In this case, I imagine a viable approach would be having rules like omitting 
the values of template arguments that have a default value, omit inlined 
namespaces, ...

> 
> That seems more interesting than a set of regular expression heuristics on 
> the type name, which is probably all you could do without specialized 
> compiler-y knowledge of types 
> 
>> 
>>> On Aug 6, 2015, at 2:33 PM, Siva Chandra >> <mailto:sivachan...@google.com>> wrote:
>>> 
>>> FWIW, GDB has a similar concept called type-printers:
>>> https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html 
>>> <https://sourceware.org/gdb/current/onlinedocs/gdb/Type-Printing-API.html>
>>> 
>>> On Thu, Aug 6, 2015 at 2:24 PM, Siva Chandra >> <mailto:sivachan...@google.com>> wrote:
>>>> Hi Enrico,
>>>> 
>>>> I was thinking about the same issue today. Could we add a concept
>>>> called "TypeNameModifier" and provide ability to define modifiers in
>>>> scripts and command line? With this, a name like
>>>> std::__1::basic_string<...> can be modified into a more friendly name
>>>> like std::string? We could ofcourse have more complex modifications.
>>>> 
>>>> I think it is doable, but what is your (and the community's) opinion
>>>> about adding such a feature? If you are OK, I would like to take up
>>>> adding such a feature.
>>>> 
>>>> Thanks,
>>>> Siva Chandra
>>>> 
>>>> On Thu, Aug 6, 2015 at 2:15 PM, Enrico Granata via lldb-dev
>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>> Hi Eugene,
>>>>> 
>>>>> On Aug 6, 2015, at 2:02 PM, Eugene Birukov via lldb-dev
>>>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am using LLDB C++ API to create custom debugger and trying to dump
>>>>> variables with their types. To do that I am using SBValue.GetTypeName() 
>>>>> API.
>>>>> Some types are OK, but some others - especially ones related to STL - are
>>>>> quite unreadable:
>>>>> 
>>>>> 
>>>>> those type names are the actual fully-specialized STL type names. I am not
>>>>> sure how to control GDB to stop truncating your string formatting, but 
>>>>> after
>>>>> the “…” there actually is more text
>>>>> It looks like what you have is std::unique_ptr > 
>>>>> >
>>>>> and those templates all take more arguments which are defaulted so you 
>>>>> don’t
>>>>> have to type them in code - but are reflected in the type name
>>>>> 
>>>>> (gdb) p value.GetTypeName()
>>>>> $1

Re: [lldb-dev] How to deal with STL type names in C++ code?

[Enrico Granata via lldb-dev]

> On Aug 6, 2015, at 4:17 PM, Siva Chandra  wrote:
> 
> 
> 
> On Thu, Aug 6, 2015 at 3:58 PM, Enrico Granata  > wrote:
> 
>> On Aug 6, 2015, at 3:50 PM, Siva Chandra > > wrote:
>> 
>> 
>> 
>> On Thu, Aug 6, 2015 at 3:38 PM, Enrico Granata > > wrote:
>> 
>>> On Aug 6, 2015, at 3:33 PM, Siva Chandra >> > wrote:
>>> 
>>> 
>>> 
>>> On Thu, Aug 6, 2015 at 2:43 PM, Enrico Granata >> > wrote:
>>> To be honest, my favorite approach would be to modify clang’s TypePrinter 
>>> to do this, and then hooking up GetDisplayTypeName() to use whatever flags 
>>> would be necessary to invoke that bit of magic
>>> 
>>> Do you mean that clang's "pretty printer" should be made extensible by a 
>>> script?
>>>  
>> 
>> Nope, what I am imagining is not an extensible system
>> 
>> When LLDB goes to print a type it asks the compiler “what is the name of 
>> this type that I should display?”
>> By default, clang prints the fully specialized template, including type 
>> arguments that have their default value. My theory is that we would want to 
>> add a mode to the type printer to say “simplify type name”, and that would 
>> do sensible things to get a display name that is more compact
>> 
>> So, how would clang know about the "simplified" or "friendly" name for a 
>> type? Even in case of standard library types, the underlying types (with 
>> unfriendly type names) could be anything. For example, libstdc++ and STLport 
>> have different underlying naming conventions. So does libc++ I would imagine 
>> (I have not spent enough time yet staring at libc++ code).
>> 
> 
> The obvious mechanism is that the compiler has knowledge of the structure of 
> the type - so it can make printing decisions based on that type structure
> In this case, I imagine a viable approach would be having rules like omitting 
> the values of template arguments that have a default value, omit inlined 
> namespaces, ...
> 
> OK. I will be on vacation next week. Will give this idea a shot after getting 
> back. 


Awesome! Looking very much forward to that!

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

[Enrico Granata via lldb-dev]

> On Aug 14, 2015, at 11:50 AM, Zachary Turner via lldb-dev 
>  wrote:
> 
> There are a bunch of tests in the tree that are named after Rdars.  As a 
> result, it's not clear to anyone outside of Apple what these are supposed to 
> be testing so it diminishes their usefulness and increases our maintenance 
> burden since it's impossible to know if it is an issue that we should fix, or 
> if it is something platform specific.
> 
> Would it be possible for someone to rename these tests to something more 
> descriptive?

I think it’s a good idea (renaming the tests)
I can definitely take on some of the renaming effort

> 
> Here is a list of some of the ones I've found:
> 
> lldb/test/functionalities/data_formatter:
> + rdar-3534688
> + rdar-9973865
> + rdar-9973992
> + rdar-9974002
> + rdar-10449092
> + rdar-10642615
> + rdar-10887661
> + rdar-11086338
> + rdar-11628688
> + rdar-11773899
> + rdar-11988289
> + rdar-12437442
> + rdar-12529957
> + rdar-13338477
> 

These are most certainly all of my own making…… *sigh*

> lldb/test/python_api:
> + rdar-12481949
> 
> lldb/test/lang/cpp:
> + rdar12991846
> 
> lldb/test/functionalities/command_script/import:
> + rdar-12586188
> 
> lldb/test/lang/objc:
> + rdar-9691614
> + rdar-10967107
> + rdar-11355592
> + rdar-12408181
> 
> For those tests which it is not possible to share more details about what the 
> test is fixing, can I request those tests be moved out of tree? 

Let us not do that if at all possible
Renaming is the correct avenue here

"If the test contents can be shared publicly, then so can a reasonable test 
name” seems a sane rule of thumb

> I assume Apple already has an internal test suite for this reason
> ___
> 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] proposal for reworked flaky test category

[Enrico Granata via lldb-dev]

> On Oct 19, 2015, at 4:40 PM, Zachary Turner via lldb-dev 
>  wrote:
> 
> Yea, I definitely agree with you there.  
> 
> Is this going to end up with an @expectedFlakeyWindows, @expectedFlakeyLinux, 
> @expectedFlakeyDarwin, @expectedFlakeyAndroid, @expectedFlakeyFreeBSD?
> 
> It's starting to get a little crazy, at some point I think we just need 
> something that we can use like this:
> 
> @test_status(status=flaky, host=[win, linux, android, darwin, bsd], 
> target=[win, linux, android, darwin, bsd], compiler=[gcc, clang], 
> debug_info=[dsym, dwarf, dwo])
> 

I think this was part of the initial intent in making the categories feature. 
That you would be able to mark tests with any number of “tags” in the form of 
categories, and then skip or execute only tests that had certain tag(s) marked 
to them

With that said, the feature as it stands:
- does not support different categories for methods in a class
-  does not allow any more complex logic than “is this category present 
on this test?”
- requires manual definition of all categories (e.g. “xfail” 
cross-product “platform” should be auto-generable)

We could extend the categories system to fix all of these issues, and then you 
could just mark tests with categories instead of attributes. Then you would 
only have one attribute that would be like

@lldbtest.categories(“win-flakey”, “linux-xfail”, “dsym”)
def test_stuff(self):
  …

> On Mon, Oct 19, 2015 at 4:35 PM Todd Fiala  > wrote:
> My initial proposal was an attempt to not entirely skip running them on our 
> end and still get them to generate actionable signals without conflating them 
> with unexpected successes (which they absolutely are not in a semantic way).
> 
> On Mon, Oct 19, 2015 at 4:33 PM, Todd Fiala  > wrote:
> Nope, I have no issue with what you said.  We don't want to run them over 
> here at all because we don't see enough useful info come out of them.  You 
> need time series data for that to be somewhat useful, and even then it only 
> is useful if you see a sharp change in it after a specific change.
> 
> So I really don't want to be running flaky tests at all as their signals are 
> not useful on a per-run basis.
> 
> On Mon, Oct 19, 2015 at 4:16 PM, Zachary Turner  > wrote:
> Don't get me wrong, I like the idea of running flakey tests a couple of times 
> and seeing if one passes (Chromium does this too as well, so it's not without 
> precedent).  If I sounded harsh, it's because I *want* to be harsh on flaky 
> tests.  Flaky tests indicate literally the *worst* kind of bugs because you 
> don't even know what kind of problems they're causing in the wild, so by 
> increasing the amount of pain they cause people (test suite running longer, 
> etc) the hope is that it will motivate someone to fix it.  
> 
> On Mon, Oct 19, 2015 at 4:04 PM Todd Fiala  > wrote:
> Okay, so I'm not a fan of the flaky tests myself, nor of test suites taking 
> longer to run than needed.
> 
> Enrico is going to add a new 'flakey' category to the test categorization.
> 
> Scratch all the other complexity I offered up.  What we're going to ask is if 
> a test is flakey, please add it to the 'flakey' category.  We won't do 
> anything different with the category by default, so everyone will still get 
> flakey tests running the same manner they do now.  However, on our test 
> runners, we will be disabling the category entirely using the skipCategories 
> mechanism since those are generating too much noise.
> 
> We may need to add a per-test-method category mechanism since right now our 
> only mechanism to add categories (1) specify a dot-file to the directory to 
> have everything in it get tagged with a category, or (2) override the 
> categorization for the TestCase getCategories() mechanism.
> 
> -Todd
> 
> On Mon, Oct 19, 2015 at 1:03 PM, Zachary Turner  > wrote:
> 
> 
> On Mon, Oct 19, 2015 at 12:50 PM Todd Fiala via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> Hi all,
> 
> I'd like unexpected successes (i.e. tests marked as unexpected failure that 
> in fact pass) to retain the actionable meaning that something is wrong.  The 
> wrong part is that either (1) the test now passes consistently and the author 
> of the fix just missed updating the test definition (or perhaps was unaware 
> of the test), or (2) the test is not covering the condition it is testing 
> completely, and some change to the code just happened to make the test pass 
> (due to the test being not comprehensive enough).  Either of those requires 
> some sort of adjustment by the developers.
> I'dd add #3.  The test is actually flaky but is tagged incorrectly.
>  
> 
> We have a category of test known as "flaky" or "flakey" (both are valid 
> spellings, for those who care: 
> http://www.merriam-webster.com/dictionary/flaky 
>