On Wed, Sep 14, 2022 at 11:21:00AM +0100, Josh Poimboeuf wrote:
> On Mon, Sep 12, 2022 at 06:31:14AM -0500, Segher Boessenkool wrote:
> > On Fri, Sep 09, 2022 at 11:07:04AM -0700, Josh Poimboeuf wrote:
> > > 2) Noreturn functions:
> > >
> > > There's no reliable way to determine which functions are designated
> > > by the compiler to be noreturn (either explictly via function
> > > attribute, or implicitly via a static function which is a wrapper
> > > around a noreturn function.)
> >
> > Or just a function that does not return for any other reason.
> >
> > The compiler makes no difference between functions that have the
> > attribute and functions that do not. There are good reasons to not
> > have the attribute on functions that do in fact not return. The
> > not-returningness of the function may be just an implementation
> > accident, something you do not want part of the API, so it *should* not
> > have that attribute; or you may want the callers to a function to not be
> > optimised according to this knowledge (you cannot *prevent* that, the
> > compiler can figure it out it other ways, but still) for any other
> > reason.
>
> Yes, many static functions that are wrappers around noreturn functions
> have this "implicit noreturn" property.
I meant functions that are noreturn intrinsically. The trivial example:
void f(void)
{
for (;;)
;
}
> I agree we would need to know
> about those functions (or, as Michael suggested, their call sites) as
> well.
Many "potentially does not return" functions (there are very many such
functions!) turn into "never returns" functions, for some inputs (or
something in the environment). If the compiler specialises a code path
that does not return, you'll not see that marked up any way. Of course
such a path should not be taken in the kernel, normally :-)
> > > 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.
The trap handler can see where the trap came from. And then look up
that address in some tables or such. Just like __bug_table?
Segher
