Two handy GDB breakpoint tricks
nullprogram.com
nullprogram.com
#include <signal.h>
int main()
{
signal(SIGTRAP, SIG_IGN);
raise(SIGTRAP);
}
When inside a debugger, requests to ignore `SIGTRAP` have no effect, unlike other signals. That's because this is literally what `SIGTRAP` is for.
In priority order:
- msvc: __debugbreak()
- clang: __builtin_debugtrap()
- linux (and probably some other posix-ish systems): raise(SIGTRAP)
- gcc x86: asm("int3; nop")
- otherwise: you're out of luck, just abort()/__builtin_trap()
catch infinite-loop
But I did think about how it could work. It could work by peridically sampling the instructions the current thread is running and detect trivial infinite loops that way.
With more effort more complicated infinite loops could be detected, but in the end not all, due to the halting problem.
edit: Actually maybe halting problem is not (theoretically) involved if you have a lot of memory: take snapshots every after every instruction. Once you take a snapshot you have already taken previously, you have found a loop. However you would still might need to somehow account for (emulate and include in snapshot?) or disallow external IO, such as time of day.
I have to admit I didn't try it out though. Maybe this changed in the meantime and it is not needed anymore.
// Q: Why is there a __nop() before __debugbreak()?
// A: VS' debug engine has a bug where it will silently swallow explicit
// breakpoint interrupts when single-step debugging either line-by-line or
// over call instructions. This can hide legitimate reasons to trap. Asserts
// for example, which can appear as if the did not fire, leaving a programmer
// unknowingly debugging an undefined process.
FWIW the actual answer is that libraries should be good at reporting / returning errors to the calling application in a reasonable manner instead of tripping assert()s or crashing the entire process. Which makes the question moot because ideally the library has few asserts to begin with.
Another feature of asserts is that `-DNDEBUG` disables them.
* frame #0: 0x00007ff818dd6fce libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007ff818e0d1ff libsystem_pthread.dylib`pthread_kill + 263
frame #2: 0x00007ff818d1b2c8 libsystem_c.dylib`raise + 26
frame #3: 0x0000000100003f6e sigtrap`main + 14
frame #4: 0x000000010001552e dyld`start + 462
Regular POSIX programmers might scoff at the very idea that this is an issue, but I always found it rather tedious having to piss about just to get back to the actual place where the break occurred so that you can inspect the state. The whole point of an assert is that you don't expect the condition to happen, so the last thing I want is to make things any more fiddly than necessary when it all goes wrong.
#define assert(c) while (!(c)) __builtin_trap()
#define assert(c) while (!(c)) __builtin_unreachable()
#define assert(c) while (!(c)) *(volatile int *)0 = 0
No, only 2 of these 3 have this property. __builtin_unreachable() tells the compiler that this code path can be assumed to never execute, with the intent to allow the compiler to optimize however it wants based on this assumption. Whether the program halts, goes into an infinite loop, executes "rm -rf /", or starts a nuclear war is up to the compiler.
(What will happen in reality is that the compiler deduces that the loop condition will never be true and therefore it can elide the entire loop.)
Sadly, other posts by this author have similar issues.
P.S.: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Jumpi...
Also, code after __builtin_trap() is treated as dead.
- in a debug build (assertions enabled) with UBSAN you get a diagnostic or trap, so far so good.
- in a debug build without UBSAN, you get… undefined behavior, possibly some optimizations. Optimizations would generally be set to a low level, but that doesn't preclude you from getting UB.
- in a release build without assertions, … the assertion would be disabled … so you don't get any optimizations; instead you get proper "DB" for the case that should never happen.
It's essentially the wrong way around. If anything this is an argument for converting assertions into this definition in a release build, which might be reasonable in some code bases. (In my main code base, we have an "assume()" macro instead; it is by policy very sparingly used to avoid risks of running into UB.)
> It's a sensible idea, this snarky comment is unwarranted.
It's not intended to be snarky, just as noted I've run into similar issues with posts by this author. I haven't counted it up but it feels like a 90% rate of being just dangerously half-right about something. (Considering how subjective perception works, 90% subjective is probably 40% actual, but still.)
(I probably should've deleted the P.S.; I reworded my post and it was a leftover.)
I think you didn't understand - what I was implying is to leave the asserts in for a release build, because they (theoretically) never happen, because they are free optimization hints.
So effectively, instead of a macro, your asserts become controlled by the presence of sanitizers.
I think it's nice because it lets you keep the same definition for both debug and release.
Remember we're not discussing our personal approaches, we're discussing what the linked post describes. It does mention UBSAN down one level of link but does not point out the pitfalls, which is the thing I'm taking issue with. I agree your approach is reasonable. It is, however, not what people reading the linked article would arrive at.
> I think it's nice because it lets you keep the same definition for both debug and release.
I would never consider turning blanket-all assert()s into assumptions for a release build. Every single assert would become a source of potential UB. This is why we have separate assert() and assume() in our codebase.
Usually articles with a title like this just find something in the documentation that the author hadn’t known, but I do often read them in the hope they’ll be like this.
gdb also supports `break -probe foo:bar` when placing some `DTRACE_PROBE(foo, bar)` at the appropriate line. I think this is likely preferable to `break func:label` now.
In x86 lingo, it’s a trap, and calling it an interrupt misses the point. int3 is a “software interrupt,” but the vector 3 is universally configured by kernels as a “trap” (by setting the appropriate mode in the IDT). So the instruction completes, IP is incremented, and the kernel is notified.
FRED tidies this all up. The kernel is notified that the event occurred and is given the length of the offending instruction.
> However, regardless of how you get an int3 in your program, GDB does not currently understand it.
GDB can’t really do better. If you have:
jnz 1f
int3
1: [non-error case here]
jnz 2f
1: [non-error case here]
2: int3
jmp 1b <— GDB sees this
Maybe a future FRED-requiring debug API could report the address of the offending int3 and GDB could use it. But ptrace is awful, gdb is awful, and I’m not convinced this will happen.
> As far as I know there is no ARM equivalent compatible with GDB (or even LLDB). The closest instruction, brk #0x1, does not behave as needed.
But doesn't elaborate on why
#define DEBUG_BREAK() do{__asm__("BKPT");} while(0)
I can continue just fine with it. Granted, this is on the various Cortex M0/M3/M4 chips, so I can't say for sure if it works on any of the bigger, fancier ARMs.
Sad... This would've made debugging much more ergonomic on my phone.