I'm trying to determine how a method Apple exposes on NSWorkspace works internally, in order to try and work around an unfortunate side effect of the method (it writes to disk, every time you call it). I can attach lldb to my executable and set a breakpoint when the method is called, and step in with si into objc_msgSend and on, but I'd prefer to just skip ahead until I get to the method body, is there any way to set a breakpoint for the beginning of the method body, or the instruction in objc_msgSend immediately before the jump to the method body?
You can set a breakpoint to the actual method body itself via something like this
br s -n "-[NSWorkspace openURL:]"
lldb's source-level step command will always pass through the objc_msgSend trampoline code for you, stopping in the target implementation, regardless of where the implementation lives.
However, lldb will also by default automatically step back out of methods with no debug info. That is for the most part the behavior people want, but is in this case NOT what you want. Fortunately, you can turn off this latter behavior, either for a given step by doing:
(lldb) step -a 0
or generally by setting the global default that controls this:
(lldb) set set target.process.thread.step-in-avoid-nodebug 0
Related
This tutorial on the GNURadio website shows that you can add a parameter to an OOT block by adding something like:
d_grey_code(grey_code)
to the block constructor after the output parameters, and adding
bool d_grey_code;
to the header file.
Doing this works fine, however, if I instantiate this block in a GR flowgraph and start a program, then "grey_code" is only updated at the start of the program.
If I set "grey code" to a variable and change it after the program starts, this change is not recongnized within the block.
Is there a method to create a parameter for an OOT block which will respond to changes in its value after a block is initialized?
Yes,
This is done via a callback. There are many examples of blocks that have callbacks. A quick look at gr-blocks and I found blocks_add_const_vxx.xml has a callback to set the constant. I suggest you look at the source for that block and understand how the "set_k" callback is defined, then try to replicate for your needs. Good luck.
- (BOOL)mySetting
{
return [myObject returnYes];
}
For a method such as the above, is it possible to add a breakpoint with a debugger command so that the -mySetting method automatically returns a different value (such as NO) when the breakpoint is enabled?
I'm looking for an option where the debugger doesn't have to interrupt execution of the app, (a.k.a. has "Automatically continue after evaluating actions" turned on).
While zylenv's answer will work, it'll require you to create a temporary variable and recompile/launch.
The proper way to do this would be to use lldb's thread return command. It is used like this:
A good blog post explaining its usage (and a bunch of other cool LLDB stuff) is here.
You can use lldb debugger to change the return value of the method.
Just did like below.
I have a method on one of my ViewController's that is called by one of its view's and delivered some value. It then sends out a message to a manager object with some information about the VC's state.
- (void)elementXChangedWithValue:(float)value {
ParameterManager * pMan = [ParameterManager sharedInstance];
[pMan updateParameter:self.elementX.parameter value:value];
}
In debugging, it was important for me to inspect what the .SomeElement.parameter state was so I could know what was getting lost in translation by the time I get to my ParameterManager.
Unfortunately, although Self is definitely non-nil and accessible the debugger shows scant information about the class making quick and practical glancing of the value difficult. (i will sometimes invoke "po" command in the debugger command line, however).
Not sure if it helps but this project is running heavy with the Objective-C/Swift interoperability although the ViewController is a fully Objective-C class.
Here is an image of what I am getting in the debugger. The drop-down arrow shows nothing but empty.
The debugger isn't perfect and sometimes you just cant see what is in certain areas, such as self. What does always work is NSLog's placed in code though, so if all else fails, add one of those in at the right place to print out the object you wish to know about.
The debugger may show more info after you make it execute these commands:
expr #import UIKit;
expr #import Foundation;
This loads the whole UIKit and Foundation symbols in the debugger at runtime, you only need to execute it once per debug session.
You can automate this with a user-defined breakpoint that'll be triggered every time your application starts in the debugger.
Source : http://furbo.org/2015/05/11/an-import-ant-change-in-xcode/
I want to create a breakpoint in xCode which uses LLDB and checks the current object class in condition section.
The problem is LLDB doesn't allow to use self to get a class. How to solve this problem? Maybe through other commands? For example, bt command output contains correct classname but it seems it is not allowed in LLDB too.
I presume this is related to:
Using of symbolic breakpoints for child classes in Xcode?
The problem comes if your breakpoint is in code with no debug information (like in system libraries.) The debugger knows nothing about self in this context, and you have to give it more help. In the case of self, you know that it was passed into a method call as the first argument, so you can use $arg1 to get at the value.
I'd like to move from NSLogging all over the place to using breakpoints for logging where the performance hit doesn't preclude it.
I know I can just po an object with a Debugger Command action, and I know I can just log any string by choosign the Log Message action.
And I think I should be able to combine both by choosing Log Message and entering something like SomeText giving context for object description: #(const char *)[[anObject description] UTF8String]#. Unfortunately, this doesn't seem to work, and always gives me what I assume to be the pointer to the description string.
What am I doing wrong?
It's kinda tricky but I think that this will work. Set the breakpoint Action as a debugger command. Then use this text as the action:
po (NSString *) [#"Some text describing: " stringByAppendingString:(NSString *)[anObject description]]
You must always be very careful to cast return types when working in the debugger. Both with GDB and LLDB.
I like your idea of using breakpoints to avoid the performance hit, but this also means that your logs will only be printed when connected to a debugger. While NSLogs will buffer their output to the system log, viewable from the Organizer (Devices) in Xcode.
(Edit: I missed the question's point and it's not an answer)
I think it's best to use DebugLog. It's a macro, and you can disable it easily (it's on when you def-ine DEBUG in your debug builds and is off when you don't define it). So, there's no performance degradation (quite the contrary).
Simply replace
NSLog(#"Hello, World!");
with
DebugLog(#"Hello, World!");
And instead of
19/4/12 8:55:52.949 PM Dictionary: Hello, World!
You'll get:
BetterDictionary.m:737 Hello, World!
(it shows which file and even which line has logged it)
Which is infinitely more interesting. undefine DEBUG for your production build and DebugLog won't be called at all.
And don't forget to #import 'DebugLog.h'.