東 lldong

Importing Hand-Rolled C Header Files in LLDB

Scenario

We're debugging a dylib, libhello.dylib
The dylib is linked from hello
The exported function is helloworld()
We do not have source, but have reversed a struct from the library and created a hand-crafted header file

Header File

If you work on a Swift project that follows the Model-View-ViewModel (MVVM) architecture or similar, you may want to jump to counterpart in Xcode from your view to your model, and then to your view model. (ie. by using Ctrl+Cmd+Up and Ctrl+Cmd+Down).

You can do this in recent versions of Xcode by setting a configuration default.

From a terminal, just type this command and press Enter:

defaults write com.apple.dt.Xcode IDEAdditionalCounterpartSuffixes -array-add "ViewModel" "View"

Compiler flag: -enforce-exclusivity=<value>
Build setting: SWIFT_ENFORCE_EXCLUSIVE_ACCESS

Xcode 10.1 & Swift 4.2

Compiler default for non optimized builds if you pass no argument is the same as if you passed checked
Compiler default for optimized builds if you pass no argument is the same as if you passed unchecked

Configuration	Compiler Flag Value	Build Setting Description	Build Setting Value	Notes

The attached lldb command pblock command lets you peek inside an Objective-C block. It tries to tell you where to find the source code for the block, and the values captured by the block when it was created.

Consider this example program:

#import <Foundation/Foundation.h>

@interface Foo: NSObject
@end

@implementation Foo

libdispatch efficiency tips

The libdispatch is one of the most misused API due to the way it was presented to us when it was introduced and for many years after that, and due to the confusing documentation and API. This page is a compilation of important things to know if you're going to use this library. Many references are available at the end of this document pointing to comments from Apple's very own libdispatch maintainer (Pierre Habouzit).

My take-aways are:

You should create very few, long-lived, well-defined queues. These queues should be seen as execution contexts in your program (gui, background work, ...) that benefit from executing in parallel. An important thing to note is that if these queues are all active at once, you will get as many threads running. In most apps, you probably do not need to create more than 3 or 4 queues.
Go serial first, and as you find performance bottle necks, measure why, and if concurrency helps, apply with care, always validating under system pressure. Reuse

	defaults write com.apple.dt.Xcode ShowDVTDebugMenu -bool YES
	sudo mkdir -p /Applications/Xcode.app/Contents/Developer/AppleInternal/Library/Xcode
	sudo touch /Applications/Xcode.app/Contents/Developer/AppleInternal/Library/Xcode/AppleInternal.plist

	# Don't forget to restart Xcode

	addmedia
	addphoto
	addvideo
	appinfo
	boot
	bootstatus
	clone
	create
	darwinup
	delete

	//
	// main.m
	// EndpointSecurityDemo
	//
	// Created by Omar Ikram on 17/06/2019 - macOS Catalina 10.15 Beta 1 (19A471t)
	// Updated by Omar Ikram on 15/08/2019 - macOS Catalina 10.15 Beta 5 (19A526h)
	// Updated by Omar Ikram on 01/12/2019 - macOS Catalina 10.15 (19A583)
	// Updated by Omar Ikram on 31/01/2021 - macOS Big Sur 11.1 (20C69)
	// Updated by Omar Ikram on 07/05/2021 - macOS Big Sur 11.3.1 (20E241)
	// Updated by Omar Ikram on 04/07/2021 - macOS Monterey 12 Beta 2 (21A5268h)

	##
	## Python commands before
	##

	def my_command(debugger, input, ctx, result, _):
	# do stuff
	pass

	def __lldb_init_module(debugger, _):
	debugger.HandleCommand(

	extension UIView {
	@objc func exerciseAmbiguityInLayoutRepeatedly() {
	if self.hasAmbiguousLayout {
	Timer.scheduledTimer(timeInterval: 0.5,
	target: self,
	selector: #selector(UIView.exerciseAmbiguityInLayout),
	userInfo: nil,
	repeats: true)
	}
	}