The same can be said about prints.
replyYes, but to a lesser extent.
reply> the debugger is likely to change the timing
replyAnd the print will 100% change the timing.
Yes, but often no where as drastic as the debugger. In Android we have huge logs anyways, a few more printf statements aren’t going to hurt.
replyLog to a memory ring buffer (if you need extreme precision, prefetch everything and write binary fixed size "log entries"), flush asynchronously at some point when you don't care about timing anymore. Really helpful in kernel debugging.
replyFormatting log still takes considerable computing, especially when working on embedded system, where your cpu is only a few hundreds MHz.
replyYou don't need to format the log on-device. You can push a binary representation and format when you need to display it. Look a 'defmt' for an example of this approach. Logging overhead in the path that emits the log messages can be tens of instructions.
replyHence the mention of binary stuff.... We use ftrace in linux and we limit ourselves a lot on what we "print".
replyNo, wrong. Totally wrong. You're changing the conditions that prevent accurate measurement without modification. This is where you use proper tools like an In-Circuit Emulator (ICE) or its equivalent.
replyI think you have a specific class of race conditions in mind where tight control of the hardware is desirable or even possible.
replyBut what to do if you have a race condition in a database stored procedure? Or in a GUI rendering code? Even web applications can experience race conditions in spite of being "single-threaded", thanks to fetches and other asynchronous operations. I never heard of somebody using ICE in these cases, nor can I imagine how it could be used - please enlighten me if I'm missing something...
> You're changing the conditions that prevent accurate measurement without modification.
Yes, but if the race condition is course-enough, like it often is in above cases, adding print/logging may not change the timings enough to hide the race.