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 <r...@remind101.com> 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 <r...@remind101.com> wrote: > That's totally fine for our use case. > > On Wed, Oct 5, 2016 at 11:57 AM, Jim Ingham <jing...@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 <r...@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 <k8st...@apple.com> 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: <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 k8st...@apple.com > > Xcode Low Level Tools > > > >> On Wed, Oct 5, 2016 at 10:06 AM, Rex Fenley <r...@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 <jing...@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@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 | 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 | BLOG | FOLLOW US | LIKE US > > > > -- > 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
