Re: [PATCH/RFC] On the use of -funreachable-traps to deal with PR 109627

[Richard Biener <richard.guenther@gmail.com>]

On Tue, Apr 9, 2024 at 6:03 AM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 4/8/24 5:04 PM, Iain Sandoe wrote:
> > Hi
> >
> > PR 109627 is about functions that have had their bodies completely elided, but still have the wrappers for EH frames (either .cfi_xxx or LFSxx/LFExx).
> >
> > These are causing issues for some linkers because such functions result in FDEs with a 0 code extent.
> >
> > The simplest representation of this is (from PR109527)
> >
> > void foo () { __builtin_unreachable (); }
> With the possibility of sounding like a broken record, I think
> __builtin_unreachable is fundamentally flawed.   It generates no code
> and just lets the program continue if ever "reached".  This is a
> security risk and (IMHO) just plain silly.  We're in a situation that is
> never supposed to happen, so continuing to execute code is just asking
> for problems.
>
> If it were up to me, I'd have __builtin_unreachable emit a trap or
> similar construct that should (in general) halt execution.

__builtin_unreachable tells the compiler it's OK to omit a path to it
while __builtin_trap doesn't.  So once we replace the former with the
latter we have to keep the path.  Maybe that's OK.  I do agree that
the RTL representation of expanding __builtin_unreachable () to
"nothing" is bad.  Expanding to a trap always would be OK with me.

Richard.

> Jeff
>