On Tue, Apr 9, 2024 at 6:03 AM Jeff Law <jeffreya...@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
>
