For reference, in the Arm documentation, the branch stream is referred to as an Instruction Trace (https://developer.arm.com/documentation/102119/0200/What-is-trace-). What we currently have in the Xcode instrument named Processor Trace is further down the page, under Instrumentation Trace. More details about the Instruction Trace can be found in the left sidebar on that page.

Note that the Processor Trace instrument does not include any options in the Instruments window, which suggests there is no way to activate the branch trace from there, even when creating a new template. So the question, more specifically, is whether the branch trace can be enabled outside of the Instruments window. If not, this could be a feature request, since a branch trace is absolutely essential for low-level analysis of performance, security, bugs, etc. Sampling is not at all sufficient.

Thanks for the pointers, there's some nice coverage using the Processor Trace template. However, it does not seem to include a sequence of "branch taken" addresses, which is available from the Embedded Trace Macrocell (ETM) in the M4 CPU. Instead of cpu cycles and instruction counts, a branch sequence is a stream of memory addresses containing program instructions, where each subsequent address indicates the next branch reached by the execution. How can I get this stream out of the ETM?

Is it necessary to enable something in the kernel for that? No instrument named "Processor Trace" appears in my xctrace list instruments, even on the mac mini M4. In any case, the Processor Trace instrument isn't sufficient for debugging low-level issues in unit tests, mainly because it's limited to function granularity. Is there anything like Intel PT, where every branch instruction is recorded?

After following the steps in the first post, it turned out to work fine from a desktop terminal, just not from ssh. Easily fixed by unlocking the keychain. For me this is a bug in the codesign error handler, which should certainly report a keychain access problem and explain how to grant it (since there is no reason to suppose the user knows how to unlock the keychain) It would be even better if codesign could just fall back to a shell-based password request when the keychain is locked