[lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(

Wed Oct 5 11:41:19 PDT 2016

Hey Kate! Thanks for all this info, it's really helpful :)

We'd like to have more complex expressions being used from the debugger.
Some of this would be code written in separate files. It will be difficult
or at least very tedious to have all our code use "$", is there a way to
void using "$"? Is there an option we could add to lldb to avoid using "$"
and still have variables and data-structures globally accessible? I notice
that within "repl" "$" it's not necessary to use any "$" variables, is
there a way to elevate the logic "repl" uses into expr?

On Wed, Oct 5, 2016 at 11:29 AM, Kate Stone <k8stone at apple.com> wrote:

> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> Maybe I have that incorrectly, this does seem to work when using lldb from
> Xcode's console. This doesn't work when typing `lldb` into the terminal and
> using it from there. I assumed the two were the same.
>
>
> The same underlying debugger is used in both cases.  There can be subtle
> reasons for differences in behavior in the different contexts, but I don’t
> see how they’d apply here.  Let’s get to a specific scenario and ensure
> that we can resolve that for you.
>
> On a separate note, --top-level doesn't seem to work for swift (from Xcode
> console lldb). We need it to work with swift for the scripts we'll be
> writing.
>
> *(lldb) expr -l swift --top-level -- let i = 10*
>
> *expr -l swift --top-level -- let a = i*
>
> error: <EXPR>:3:9: error: use of unresolved identifier 'i'
>
> The --top-level option isn’t meaningful for Swift, so it’s completely
> ignored.  The less ambiguous nature of the language allows us to
> automatically determine what are top-level constructs and what’s intended
> to be evaluated in scope.  We introduced --top-level for Objective-C / C++
> primarily to enable declaring functions and anything else that literally
> *cannot* be written in a local scope.
>
> In your particular example the reason you can’t refer to “i” is completely
> unrelated.  Conceptually, every expression you evaluate is wrapped in its
> own scope.  So your two subsequent expressions act like this construct :
>
> do {
>     let i = 10
> }
> do {
>     let a = i
> }
>
>
> As you can see, “i” is defined in this expression scope and then goes out
> of scope immediately after execution.  This is useful when you want to
> write a multi-line expression that introduces declarations for immediate
> use without having them cluttering up your namespace afterwards.  The
> convention used by LLDB for any declaration that you intend to use in later
> expressions is to prefix the name with a dollar sign.  So you can do the
> following:
>
> (lldb) expr -l swift -- let $i = 10
> (lldb) expr -l swift -- let $a = i
>
>
> … and both “$a” and “$i" will be available in subsequent expressions.
>
> Kate Stone k8stone at apple.com
>  Xcode Low Level Tools
>
> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley <rex at remind101.com> wrote:
>
>> Jim,
>>
>> That doesn't seem to work for us. We're using lldb packaged with Xcode 8
>> fyi.
>>
>> (lldb) expr --top-level -- NSString *string = [NSString
>> stringWithUTF8String: "This is a string"];
>>
>>
>> ; Function Attrs: nounwind
>>
>> define internal void @_GLOBAL__sub_I__null_() #0 section
>> "__TEXT,__StaticInit,regular,pure_instructions" {
>>
>>   call void @__cxx_global_var_init()
>>
>>   ret void
>>
>> }
>>
>> On Tue, Oct 4, 2016 at 4:09 PM, Jim Ingham <jingham at apple.com> wrote:
>>
>>> This isn't an issue with ObjC support in general, but rather shows that
>>> ObjC string constants are odd beasts.  You can work around this pretty
>>> easily by making dynamic strings:
>>>
>>> (lldb) expr --top-level -- NSString *string = [NSString
>>> stringWithUTF8String: "This is a string"];
>>> (lldb) expr string
>>> (__NSCFString *) $0 = 0x00000001002001b0 @"This is a string"
>>>
>>> Please file a bug about the problem with ObjC constant strings.
>>>
>>> Jim
>>>
>>>
>>> > On Oct 4, 2016, at 3:57 PM, Rex Fenley via lldb-dev <
>>> lldb-dev at lists.llvm.org> wrote:
>>> >
>>> > Hey lldb team!
>>> >
>>> > I'm trying to use `expr --top-level` from lldb in Xcode but it throws
>>> errors like the following:
>>> >
>>> > (lldb) expression --top-level -- NSString *str = @"This is a string";
>>> > Error [IRForTarget]: Couldn't replace an Objective-C constant string
>>> with a dynamic string
>>> > error: cannot import unsupported AST node ObjCStringLiteral
>>> > error: The expression could not be prepared to run in the target
>>> >
>>> > It seems like top-level only supports raw C code and not Objective-C.
>>> Is there an option we can set to support this? Is there somewhere in lldb's
>>> source code that could help point us to fixing this?
>>> >
>>> > Thank you, you guys rule!
>>> >
>>> > --
>>> > Rex Fenley  |  IOS DEVELOPER
>>> >
>>> >
>>> > Remind.com |  BLOG  |  FOLLOW US  |  LIKE US
>>> > _______________________________________________
>>> > lldb-dev mailing list
>>> > lldb-dev at lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>> --
>> Rex Fenley  |  IOS DEVELOPER
>>
>> Remind.com <https://www.remind.com/> |  BLOG <http://blog.remind.com/>
>>  |  FOLLOW US <https://twitter.com/remindhq>  |  LIKE US
>> <https://www.facebook.com/remindhq>
>>
>
>
>
> --
> Rex Fenley  |  IOS DEVELOPER
>
> Remind.com <https://www.remind.com/> |  BLOG <http://blog.remind.com/>  |
>  FOLLOW US <https://twitter.com/remindhq>  |  LIKE US
> <https://www.facebook.com/remindhq>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>

-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com <https://www.remind.com/> |  BLOG <http://blog.remind.com/>
 |  FOLLOW
US <https://twitter.com/remindhq>  |  LIKE US
<https://www.facebook.com/remindhq>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20161005/64e72f8c/attachment-0001.html>