How does one set a symbolic breakpoint in lldb when using Swift? For example, sometimes I use:
(lldb) b set -F '-[UIView(AdditionalLayoutSupport) updateConstraintsIfNeeded]'
But this no longer works:
Breakpoint 2: no locations (pending). WARNING: Unable to resolve
breakpoint to any actual locations.
I've also tried
(lldb) b set -F 'UIView.updateConstraintsIfNeeded()'
(lldb) b set -F 'UIView.updateConstraintsIfNeeded'
But no love. I guess the question comes down to what lldb considers a "fully qualified function name" when using Swift. The docs say:
-F ( --fullname )
Set the breakpoint by fully qualified function names. For C++ this
means namespaces and all arguments, and for Objective C this means
a full function prototype with class and selector. Can be repeated
multiple times to make one breakpoint for multiple names.
What about Swift?
When lldb is setting breakpoints any of the fancier matching breakpoints (including -F), it needs to know the target language since the kinds of matching it does depends on that. By default, lldb chooses the language of the current frame, but you can override that. So for instance to break on an ObjC symbol when you are stopped in a Swift frame, do:
(lldb) break set -F '-[UIView(AdditionalLayoutSupport) updateConstraintsIfNeeded]' -L objc
Breakpoint 3: where = UIKit`-[UIView(AdditionalLayoutSupport) updateConstraintsIfNeeded], address = 0x0000000100963acc
Or you can use the -n break option, which doesn't try to understand the symbols it matches, but just does a wide search for that string in the symbol names.
Note, in this case you need to break on the ObjC symbol not the way it appears in Swift, because the swift side is really just a shim into objc, and there isn't really a swift side symbol to hook onto.
In the lldb console, you can give a partial name and get automatic lookup using regex:
br set -r updateConstraintsIfNeeded\]
The result is:
Breakpoint 4: where = UIKit`-[UIView(AdditionalLayoutSupport) updateConstraintsIfNeeded]
In current versions of Xcode, you can also use a partial name in the "add a symbolic breakpoint" UI, because there is now code completion to assist you.
Related
I have a large Swift project that's technically a mixed project, as it has a small amount of Objective-C code. But whenever I drop into LLDB, the expression evaluator is expecting Objective-C syntax. I can use Swift with e -l swift -- but this is tedious to type every time.
Can I default the LLDB expression evaluator to Swift?
There is a target level setting to force the language:
(lldb) settings set target.language swift
Or you can make an alias for swift specific expressions:
command alias es expression -l swift --
In this thread the meaning of the # symbol is explained:
What does the '#' symbol mean in Swift?
In the thread # is said to identify an attribute. But there's another statement saying it's a "compiler directive". I've also learned that the Objective-C like Swift statement:
#autoreleasepool {...} nowdays can be used without the # symbol.
So this leaves me quite puzzled. What is the actual meaning of the # symbol itself? It seems to me it can be used for more than attributes but I've found no document explaining the exact rules for how to use #. Mostly I find examples on how to use it as an attribute.
Or is it that the language has changed lately and nowdays, with Swift 4, # is for attributes only?
EDIT: Since I had remarks I should not ask about Swift and Objective C in the same thread I've edited the text to focus on Swift.
In WinDbg, I can get the callstack using the k command. For DLLs without symbols, it displays an incorrect method name and a large offset, e.g.
0018f9f0 77641148 syncSourceDll_x86!CreateTimerSyncBridge+0xc76a
Since I don't have symbols, I have to give this information to the developer of the DLL. I don't know who will work on the bug and how much debugging knowledge he has. I want to avoid that the developer thinks the problem is in the CreateTimerSyncBridge() method.
Is there a way to get the callstack without method names, just with offsets?
At the moment I'm using the following workaround:
0:000> ? syncSourceDll_x86!CreateTimerSyncBridge+0xc76a
Evaluate expression: 1834469050 = 6d57c6ba
0:000> ? syncSourceDll_x86
Evaluate expression: 1834287104 = 6d550000
0:000> ? 6d57c6ba-6d550000
Evaluate expression: 181946 = 0002c6ba
So I can modify the callstack manually to
0018f9f0 77641148 syncSourceDll_x86!+0x2c6ba
But that's really hard to do for a lot of frames in a lot of threads.
You can specify that the symbols must match exactly using a stricter evaluation, either by starting windbg with command line parameter -ses or issuing the command:
.symopt +0x400
The default is false for the debugger, if you wish to reset this then just remove the option:
.symopt -0x400
See the msdn docs: https://msdn.microsoft.com/en-us/library/windows/hardware/ff558827(v=vs.85).aspx#symopt_exact_symbols
After swaping compiler to LLVM 3.0 and libc++ to have C++11 suport (unique_ptr is a little jewel :)) I have noticed gdb is not working properly when I try to print an object information. What I have tested is the following:
1) I have a std::vector < std::unique_ptr > member variable. If I set a breakpoint inside the class containing this member var and do a "print _reusableEntities.size()" I get this:
Breakpoint 2, GameObjectMgr::createGameObject (this=0x0) at /Users/hexdump/Dropbox/Games prototypes/Re-World/src/ReWorld/Engine/EntityManagement/GameObjectMgr.mm:92
92 go=std::move(_reusableEntities.back());
The program being debugged stopped while in a function called from GDB.
When the function (GameObjectMgr::createGameObject()) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
But if I have a line of code like:
int size=_reusableEntities.size()
it reads the size ok. It really seems a gdb problem when inspecting the vector size. In the other hand I can see how the vector contains correct values in the Local vars windows.
Another thing that is really weird is why the error shows information related to createGameObject function because It has nothing to do with the gdb command call and I wasn't inside it when trying to print the values.
It is really weird and a pain in the ass when debugging.
2) I have F7 configured to step over functions. This worked until I made this changes, now, it doesn't matter if I push F6 (step into) or F7 (step over) I'm always getting inside unique_ptr code when copying, or getting raw pointer from it :/.
If anyone could guess what is happening I would be really grateful, anyway, I know it is really difficult to guess from just my explanation. If anyone needs more info, please, ask for it.
I've only recently began using the debugger extensively, so I'm not sure if this is a limitation.
When I debug on the iPhone, the variables aren't up to date unless I explicitly view it (ctrl+click -> view variable as expression). Is there a way to view actual variables without viewing explicitly?
Can you clarify your question? You should only be viewing data while the program is stopped -- examining data while it's running, if it works at all, is much less useful. Make sure to set a breakpoint, and then examine data once you've hit the breakpoint.
An alternative to using Xcode's built-in debugging features is to use the gdb console. Type ⌘-Shift-R, or select "Debugging Console" from the menu to open the console. Then, you can type commands like:
# View a variable
print var
# View this object's member variable
print self->memberVar
# Ask an Objective-C object to print itself:
print-object self
You should use print with primitive types (int, char*, etc.) and POD types (structs); you should use print-object with Objective-C objects (NSString, etc.). For more information about print and print-object, type
help print
help print-object
You can also use the abbreviations p and po for print and print-object respectively.