[swift-lldb-dev] Swift LLDB Feature Support

[Jim Ingham]

> On Oct 5, 2016, at 5:01 PM, Jessie Serrino via swift-lldb-dev <swift-lldb-dev at swift.org> wrote:
> 
> Hi Swift LLDB,
> 
> First of all, thanks to some of you for being so responsive!
> 
> After playing around a bit with the LLDB build, we had some feature requests for the next version of LLDB.
> 
> First and foremost, we’d like to be able to execute multi-line expressions through expression, and create variables in a global context without a $. This is incredibly important, and would enable us (and other developers) to make deeper, more valuable investigations into code while debugging.

Not sure what you mean by this.  If you mean read a multi-line expression from a file, then that's a long-standing request, and should be pretty straight-forward to add.  But you can just do:

(lldb) expr
Enter expressions, then terminate with an empty line to evaluate:
  1:  //Start writing code
  2:  //Some more code
  3:
(lldb)

Also, both SBFrame.EvaluateExpression and SBTarget.EvaluateExpression take in a python string, which can certainly have newlines.

So there are already ways to do this.  

For the C family of languages, using the --top-level will allow you to create variables in the global context w/o $, that can be used in other expressions:

(lldb) expr --top-level -- int NoSuchVariable = 10;
(lldb) expr printf("%d\n", NoSuchVariable)
10
(int) $0 = 3

so you can already do that.

Similarly in Swift, you can do:

(lldb) repl 
  1> var NoSuchVariable : Int = 10
NoSuchVariable: Int = 10
  2> ^D
(lldb) expr print("Value: \(NoSuchVariable)")
Value: 10

The bug to fix here is that --top-level isn't currently wired up for Swift.  That should get wired up to do exactly what the REPL does, but just not require the interactive part.

It seems to me worthwhile to make an explicit statement that you are adding global definitions that will take their place in lookups at the global scope.  And having --top-level be the one that can introduce those definitions seems a perfectly clear way to do this to me.

OTOH, if I were writing a bunch of expression code that could be injected into the target process and then run for investigation purposes from the expr command, and that code relied on some global variable state, I would personally never use variables w/o $'s in front.  That way I'd never find myself in the case where some user tries to run your investigation code who has a local variable with the same name as your variables, and they'll get some weird error they won't understand because of the shadowing.

> 
> In a similar vein, we would like to be able to revert these definitions of expressions in Swift. This would allow us to set the state for certain variables, but also revert our code if anything were to go awry.

It would be pretty straight-forward to dump the whole state that you've built up in expressions.  All that information is stored in the "ScratchTypeSystem" for a given language.  See lldb_private::Target::GetScratchTypeSystem*.  So you could just jettison that.  You'd have to be careful because the ScratchTypeSystem also stores utility functions that lldb uses internally.  So you'd probably need to make an internal scratch space, and use that where we make UtilityFunctions and the like.  But this shouldn't be all that hard.

It would be much trickier to try to throw away individual expressions.  I'm not sure the benefits of this would really be worth the trouble.

> 
> Would it be possible to have some help with this? We're relatively new to the codebase, so we've been having trouble getting things kickstarted on our end.
> 

We are certainly available to answer questions and help you get started.

Jim


> Thanks again,
> Jessie (and Rex)
> 
> -- 
> Jessie Serrino
> iOS Engineer, Remind
> 
> _______________________________________________
> swift-lldb-dev mailing list
> swift-lldb-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-lldb-dev