The only special constructs supported by the Log message are the breakpoint name and hit count (%B, %H respectively) and the construct @expression_text@ which (roughly) runs expr expression_text and substitutes the result into the string.
For instance, you could write an expression that would print the type of self pretty easily. For an ObjC method the log string:
Called class: @self.className@
Produces:
Called class: @"AppDelegate"
However, you won't be able to get the current method name using an expression because of how the lldb expression evaluation is implemented. lldb can't run code actually IN the stack frame where you are stopped, instead, it has to make a special function and remap the current locals/class context, etc to that. Reusing the original function name was trickier than it was worth, so instead the code runs in a function with some lldb internal name.
However, you could write a python command that outputs exactly what you want, and add that python command to your breakpoints, for instance put this:
import lldb
def my_printer(debugger, command, exe_ctx, result, dict):
name = exe_ctx.frame.symbol.name
result.Print(f"Current method: {name}")
def __lldb_init_module(debugger, dict):
debugger.HandleCommand(f"command script add my_command -f {__name__}.my_printer")
in a python file somewhere, and in lldb (or even in your ~/.lldbinit) do:
command script import "path to the py file"
Then you can add "my_command" as a "Debugger Command" action to your breakpoint, and it will print the current method name.
It looks like there is a syslog python module that prints to OS log - though I have not used it - but if it works as advertised you could certainly use that in this command if you need the output to go to the os_log as well.
BTW, command script import has a -c option which means "look relative to the current script file". That's handy, for instance, if you use Xcode's per-target LLDBInit and store the script file & the LLDBInit in the project.
