Hello,
On Wed, 14 Sep 2022, Josh Poimboeuf wrote:
> > > 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.
