Hello,
On Wed, 14 Sep 2022, Josh Poimboeuf wrote:
quoted
quoted
This information is needed because the
code after the call to such a function is optimized out as
unreachable and objtool has no way of knowing that.
Since June we (GCC) have -funreachable-traps. This creates a trap insn
wherever control flow would otherwise go into limbo.
Ah, that's interesting, though I'm not sure if we'd be able to
distinguish between "call doesn't return" traps and other traps or
reasons for UD2.
There are two reasons (which will turn out to be the same) for a trap (say
'UD2' on x86-64) directly after a call insn:
1) "the call shall not have returned"
2) something else jumps to that trap because it was __builtin_unreachable
(or equivalent), and the compiler happened to put that ud2 directly
after the call. It could have done that only when the call itself was
noreturn:
cmp $foo, %rax
jne do_trap
call noret
do_trap:
ud2
So, it's all the same. If there's an ud2 (or whatever the trap maker is)
after a call then it was because it's noreturn.
(But, of course this costs (little) code size, unlike the non-alloc
checker sections)
Ciao,
Michael.