Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
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 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 = 0x0001002001b0 @"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@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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
--
Rex Fenley | IOS DEVELOPER
Remind.com | LIKE US
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
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.
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: :3:9: error: use of unresolved identifier 'i'
let a = i
On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley 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 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 = 0x0001002001b0 @"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@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@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
>
> Rex Fenley | IOS DEVELOPER
>
> Remind.com | LIKE US
>
>
--
Rex Fenley | IOS DEVELOPER
Remind.com | LIKE US
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
> On Oct 5, 2016, at 10:06 AM, Rex Fenley 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
>
> }
>
>
Yes, I see that printout too, but it doesn't make the expression not work.
With 8.0 I see:
(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
}
(lldb) po string
This is a string
So the expression definitely worked.
Can you file a bug about the spammy printing? Looks like somebody left a
printf in code somewhere.
Jim
> On Tue, Oct 4, 2016 at 4:09 PM, Jim Ingham 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 = 0x0001002001b0 @"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
> > 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@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
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
Sure, I'll file a bug :)
Can we get --top-level to work with Swift too?
On Wed, Oct 5, 2016 at 11:03 AM, Jim Ingham wrote:
>
> > On Oct 5, 2016, at 10:06 AM, Rex Fenley 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
> >
> > }
> >
> >
>
> Yes, I see that printout too, but it doesn't make the expression not
> work. With 8.0 I see:
>
> (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
> }
>
> (lldb) po string
> This is a string
>
> So the expression definitely worked.
>
> Can you file a bug about the spammy printing? Looks like somebody left a
> printf in code somewhere.
>
> Jim
>
> > On Tue, Oct 4, 2016 at 4:09 PM, Jim Ingham 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 = 0x0001002001b0 @"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@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@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > Rex Fenley | IOS DEVELOPER
> >
> >
> > Remind.com | BLOG | FOLLOW US | LIKE US
>
>
--
Rex Fenley | IOS DEVELOPER
Remind.com | LIKE US
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev
> 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: :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 k8st...@apple.com
Xcode Low Level Tools
> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley > 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 > 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 = 0x0001002001b0 @"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
> > mailto:lldb-dev@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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
>
>
>
> --
> Rex Fenley | IOS DEVELOPER
>
>
> Remind.com | LIKE US
>
>
>
> --
> Rex Fenley | IOS DEVELOPER
>
>
> Remind.com | LIKE US
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.o
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
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 wrote:
> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev <
> lldb-dev@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: :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 k8st...@apple.com
> Xcode Low Level Tools
>
> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley 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 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 = 0x0001002001b0 @"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@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@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
You would have to be really careful about using "debugger variables" whose name
is not decorated with a "$". After all, this is introducing a global variable,
which will be shadowed by local variables, ivars, file statics for the current
frame's CU, etc. So using the code you've added at various stop points in the
debugging session will be fragile. That's the primary reason that we don't
encourage defining debugger variables in the common identifier namespace of
your program.
Jim
> On Oct 5, 2016, at 11:41 AM, Rex Fenley wrote:
>
> 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 wrote:
>> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev
>> 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: :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 k8st...@apple.com
> Xcode Low Level Tools
>
>> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley 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 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 = 0x0001002001b0 @"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
>> > 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
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
That's totally fine for our use case.
On Wed, Oct 5, 2016 at 11:57 AM, Jim Ingham wrote:
> You would have to be really careful about using "debugger variables" whose
> name is not decorated with a "$". After all, this is introducing a global
> variable, which will be shadowed by local variables, ivars, file statics
> for the current frame's CU, etc. So using the code you've added at various
> stop points in the debugging session will be fragile. That's the primary
> reason that we don't encourage defining debugger variables in the common
> identifier namespace of your program.
>
> Jim
>
>
>
> > On Oct 5, 2016, at 11:41 AM, Rex Fenley wrote:
> >
> > 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 wrote:
> >> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev <
> lldb-dev@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: :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 k8st...@apple.com
> > Xcode Low Level Tools
> >
> >> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley 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 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 = 0x0001002001b0 @"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@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
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
Hey!
I tried building the LLDB target from within Xcode in order to gain
understanding of how this system works at the source level. However, I get
the following error during compilation:
subprocess.CalledProcessError: Command '['python',
'/Users/Rex/Documents/projects/swift-lldb/llvm/tools/swift/utils/build-script',
'--preset=LLDB_Swift_ReleaseAssert',
'swift_install_destdir=/Users/Rex/Documents/projects/swift-lldb/llvm-build/ReleaseAssert/swift-macosx-x86_64']'
returned non-zero exit status 1
And much further up I see
warning: A compatible version of re2c (>= 0.11.3) was not found; changes to
src/*.in.cc will not affect your build.
and
error: unknown setting: cmark-cmake-options
How may I fix this/these issues to build and run lldb from Xcode?
On Wed, Oct 5, 2016 at 12:05 PM, Rex Fenley wrote:
> That's totally fine for our use case.
>
> On Wed, Oct 5, 2016 at 11:57 AM, Jim Ingham wrote:
>
>> You would have to be really careful about using "debugger variables"
>> whose name is not decorated with a "$". After all, this is introducing a
>> global variable, which will be shadowed by local variables, ivars, file
>> statics for the current frame's CU, etc. So using the code you've added at
>> various stop points in the debugging session will be fragile. That's the
>> primary reason that we don't encourage defining debugger variables in the
>> common identifier namespace of your program.
>>
>> Jim
>>
>>
>>
>> > On Oct 5, 2016, at 11:41 AM, Rex Fenley wrote:
>> >
>> > 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 wrote:
>> >> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev <
>> lldb-dev@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: :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 k8st...@apple.com
>> > Xcode Low Level Tools
>> >
>> >> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley 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 voi
Re: [lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
This isn't the appropriate place to discuss lldb-swift build problems, since
the swift support is not actually in the llvm.org tree. A better mailing list
would be:
https://lists.swift.org/mailman/listinfo/swift-lldb-dev
Jim
> On Oct 5, 2016, at 12:25 PM, Rex Fenley wrote:
>
> Hey!
>
> I tried building the LLDB target from within Xcode in order to gain
> understanding of how this system works at the source level. However, I get
> the following error during compilation:
> subprocess.CalledProcessError: Command '['python',
> '/Users/Rex/Documents/projects/swift-lldb/llvm/tools/swift/utils/build-script',
> '--preset=LLDB_Swift_ReleaseAssert',
> 'swift_install_destdir=/Users/Rex/Documents/projects/swift-lldb/llvm-build/ReleaseAssert/swift-macosx-x86_64']'
> returned non-zero exit status 1
>
> And much further up I see
>
> warning: A compatible version of re2c (>= 0.11.3) was not found; changes to
> src/*.in.cc will not affect your build.
>
>
> and
>
> error: unknown setting: cmark-cmake-options
>
> How may I fix this/these issues to build and run lldb from Xcode?
>
>
> On Wed, Oct 5, 2016 at 12:05 PM, Rex Fenley wrote:
> That's totally fine for our use case.
>
> On Wed, Oct 5, 2016 at 11:57 AM, Jim Ingham wrote:
> You would have to be really careful about using "debugger variables" whose
> name is not decorated with a "$". After all, this is introducing a global
> variable, which will be shadowed by local variables, ivars, file statics for
> the current frame's CU, etc. So using the code you've added at various stop
> points in the debugging session will be fragile. That's the primary reason
> that we don't encourage defining debugger variables in the common identifier
> namespace of your program.
>
> Jim
>
>
>
> > On Oct 5, 2016, at 11:41 AM, Rex Fenley wrote:
> >
> > 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 wrote:
> >> On Oct 5, 2016, at 10:14 AM, Rex Fenley via lldb-dev
> >> 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: :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 k8st...@apple.com
> > Xcode Low Level Tools
> >
> >> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley wrote:
> >> Jim,
> >>
> >> That doesn't seem to work for us. We're using lldb packaged w
Re: [lldb-dev] NetBSD buildbot new machine
New machine is up and running. There is more power and it builds the whole distribution within 35 minutes. On 04.10.2016 15:13, Kamil Rytarowski via lldb-dev wrote: > Hello, > > I'm in process of switching a machine for NetBSD buildbot. It will be > temporarily unavailable. > > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > signature.asc Description: OpenPGP digital signature ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
