On Fri, Feb 24, 2017 at 01:53:27AM -0800, H. Peter Anvin wrote: > On 02/24/17 01:15, Ingo Molnar wrote: > > > > * h...@zytor.com <h...@zytor.com> wrote: > > > >> Incidentally, as an alternative to a #UD, int $9 could be an alternative > >> (exception vector 9 was discontinued with the 486.) > > > > With thousands of call sites a one byte opcode would be preferred, that's > > why INT3 > > is so nice. > > > > Yes, but using INT3 would bugger up debuggers.
So I've been looking into this, in general debuggers will refuse to poke INT3 on top of INT3 (sane and obvious behaviour). Also, we'd run any actual handlers before fixup_bug(), the only thing here is that we need to also do fixup_bug() if the instruction pointer isn't changed. This would allow debuggers to effectively stack on top of the already present breakpoint. Optimized kprobes will make sure to not clobber INT3 (although it will happily clobber anything else from __ex_table[]). The only other point is that currently report_bug() relies on is_valid_bugaddr() to tell if the instruction is 'good', but then reports a BUG if there is no entry in __bug_table[]. We'd have to change that to be strict and assume __bug_table[] is complete, and report BUG_TRAP_TYPE_NONE when there is no __bug_table[] entry, this would also avoid the need for is_valid_bugaddr(). So yes, its tricky but it could be done. A new single byte #UD instruction would be much nicer though.
