https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82158
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
--- Comment #4 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Peter Cordes from comment #3)
> (In reply to jos...@codesourcery.com from comment #2)
> > Falling off a noreturn function sounds like it could be another case to
> > insert __builtin_trap (), as we do in various cases of undefined behavior.
>
> gcc has had a `-mabort-on-noreturn` option for ARM32 for a long time, but
> it's not enabled by default.
>
> I'm still not sure if clobbering r5 when the function really doesn't return
> is a feature (which gcc should be doing for other targets) or a bug.
It's a "feature" - if the function really doesn't return, then there is no real
requirement to save and restore all callee-saved registers.
A deliberate choice when computing the save register mask - all that we are
providing is an ability to backtrace out of such cases - anything more is just
broken and sort of defeats the purpose of noreturn functions in the first
place.
I can see that other backends have similar techniques - x86_64 appears to trash
%esi in the experiments I did and it does look like %esi is a callee saved
register.
>
> It clearly breaks stack unwinding of call-preserved register values with
> x86-64 style .eh_frame metadata; does this matter for exceptions from
> callees of the noreturn function, or only for debugging?
Arm doesn't turn on exception tables by default very unlike x86_64 - if you
want eh information from C then use -fexceptions on the command line and I see
that it all works just fine.
>
> Anyway, gcc should either produce a compile-time error, call
> __builtin_trap() or abort(), or properly restore all call-preserved
> registers when it returns. There should be no set of options that lets it
> make bad code like this, even with a warning.
It does produce a warning , you could use -Werror :) ? We could look to put out
a __builtin_trap instead of a call to abort in the backend - As you say
-mabort-on-noreturn has existed since time immemorial , maybe we have to
replace that with a trap instruction and discuss whether to turn it on by
default.
