[lldb-dev] --top-level doesn't work in lldb for Objective-C or Swift :(
Rex Fenley via lldb-dev
lldb-dev at lists.llvm.org
Wed Oct 5 12:25:31 PDT 2016
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 <rex at remind101.com> wrote:
> That's totally fine for our use case.
>
> On Wed, Oct 5, 2016 at 11:57 AM, Jim Ingham <jingham at apple.com> 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 <rex at remind101.com> 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 <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 | BLOG | FOLLOW US | LIKE US
>> >>
>> >>
>> >>
>> >> --
>> >> 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 | BLOG | FOLLOW US | LIKE US
>>
>>
>
>
> --
>
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20161005/05f982eb/attachment-0001.html>
More information about the lldb-dev
mailing list