llvm dev - Jul 2020 - [cfe-dev] Zero length function pointer equality

Looks perfect to me!

well, a couple of questions: Why a noop, rather than int3/ud2/etc?
Might be worth using the existing code that places such an instruction
when building at -O0?
& you mention that this causes problems on Windows - but ICF done by
the Windows linker does not cause such problems? (I'd have thought
they'd result in the same situation - two functions described as being
at the same address?) is there a quick summary of why those two cases
turn out differently?

On Fri, Jul 24, 2020 at 6:17 AM Hans Wennborg <hans at chromium.org>
wrote:
>
> Maybe we can just expand this to always apply:
https://reviews.llvm.org/D32330
>
> On Fri, Jul 24, 2020 at 2:46 AM David Blaikie via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > LLVM can produce zero length functions from cases like this (when
> > optimizations are enabled):
> >
> > void f1() { __builtin_unreachable(); }
> > int f2() { /* missing return statement */ }
> >
> > This code is valid, so long as the functions are never called.
> >
> > I believe C++ requires that all functions have a distinct address (ie:
> > &f1 != &f2) and LLVM optimizes code on this basis (assert(f1
== f2)
> > gets optimized into an unconditional assertion failure)
> >
> > But these zero length functions can end up with identical addresses.
> >
> > I'm unaware of anything in the C++ spec (or the LLVM langref) that
> > would indicate that would allow distinct functions to have identical
> > addresses - so should we do something about this in the LLVM backend?
> > add a little padding? a nop instruction? (if we're adding an
> > instruction anyway, perhaps we might as well make it an int3?)
> >
> > (I came across this due to DWARF issues with zero length functions
&
> > thinking about if/how this should be supported)
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On Sat, Jul 25, 2020 at 3:40 AM David Blaikie <dblaikie at gmail.com>
wrote:
>
> Looks perfect to me!
>
> well, a couple of questions: Why a noop, rather than int3/ud2/etc?
Probably no reason.
> Might be worth using the existing code that places such an instruction
> when building at -O0?
I wasn't aware of that. Does it happen for all functions (e.g. I think
I got pulled into this due to functions with the naked attribute)?
> & you mention that this causes problems on Windows - but ICF done by
> the Windows linker does not cause such problems? (I'd have thought
> they'd result in the same situation - two functions described as being
> at the same address?) is there a quick summary of why those two cases
> turn out differently?
The case that we hit was that the Control Flow Guard table of
addresses in the binary ended up listing the same address twice, which
the loader didn't expect. It may be that the linker took care to avoid
that for ICF (if two ICF'd functions got the same address, only list
it once in the CFG table) but still didn't handle the "empty
function"
problem.
> On Fri, Jul 24, 2020 at 6:17 AM Hans Wennborg <hans at chromium.org>
wrote:
> >
> > Maybe we can just expand this to always apply:
https://reviews.llvm.org/D32330
> >
> > On Fri, Jul 24, 2020 at 2:46 AM David Blaikie via cfe-dev
> > <cfe-dev at lists.llvm.org> wrote:
> > >
> > > LLVM can produce zero length functions from cases like this (when
> > > optimizations are enabled):
> > >
> > > void f1() { __builtin_unreachable(); }
> > > int f2() { /* missing return statement */ }
> > >
> > > This code is valid, so long as the functions are never called.
> > >
> > > I believe C++ requires that all functions have a distinct address
(ie:
> > > &f1 != &f2) and LLVM optimizes code on this basis
(assert(f1 == f2)
> > > gets optimized into an unconditional assertion failure)
> > >
> > > But these zero length functions can end up with identical
addresses.
> > >
> > > I'm unaware of anything in the C++ spec (or the LLVM langref)
that
> > > would indicate that would allow distinct functions to have
identical
> > > addresses - so should we do something about this in the LLVM
backend?
> > > add a little padding? a nop instruction? (if we're adding an
> > > instruction anyway, perhaps we might as well make it an int3?)
> > >
> > > (I came across this due to DWARF issues with zero length
functions &
> > > thinking about if/how this should be supported)
> > > _______________________________________________
> > > cfe-dev mailing list
> > > cfe-dev at lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Hans
> Wennborg via llvm-dev
> Sent: Monday, July 27, 2020 9:11 AM
> To: David Blaikie <dblaikie at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Clang Dev <cfe-dev at
lists.llvm.org>
> Subject: Re: [llvm-dev] [cfe-dev] Zero length function pointer equality
> 
> On Sat, Jul 25, 2020 at 3:40 AM David Blaikie <dblaikie at gmail.com>
wrote:
> >
> > Looks perfect to me!
> >
> > well, a couple of questions: Why a noop, rather than int3/ud2/etc?
> 
> Probably no reason.
FTR there is TargetOptions.TrapUnreachable, which some targets turn on
(for X86 it's on for MachO and PS4), this turns 'unreachable' into
ud2.
Clearly it covers more than "empty" functions but is probably the kind
of thing you're looking for.
--paulr
> 
> > Might be worth using the existing code that places such an instruction
> > when building at -O0?
> 
> I wasn't aware of that. Does it happen for all functions (e.g. I think
> I got pulled into this due to functions with the naked attribute)?
> 
> > & you mention that this causes problems on Windows - but ICF done
by
> > the Windows linker does not cause such problems? (I'd have thought
> > they'd result in the same situation - two functions described as
being
> > at the same address?) is there a quick summary of why those two cases
> > turn out differently?
> 
> The case that we hit was that the Control Flow Guard table of
> addresses in the binary ended up listing the same address twice, which
> the loader didn't expect. It may be that the linker took care to avoid
> that for ICF (if two ICF'd functions got the same address, only list
> it once in the CFG table) but still didn't handle the "empty
function"
> problem.
> 
> > On Fri, Jul 24, 2020 at 6:17 AM Hans Wennborg <hans at
chromium.org> wrote:
> > >
> > > Maybe we can just expand this to always apply:
> https://reviews.llvm.org/D32330
> > >
> > > On Fri, Jul 24, 2020 at 2:46 AM David Blaikie via cfe-dev
> > > <cfe-dev at lists.llvm.org> wrote:
> > > >
> > > > LLVM can produce zero length functions from cases like this
(when
> > > > optimizations are enabled):
> > > >
> > > > void f1() { __builtin_unreachable(); }
> > > > int f2() { /* missing return statement */ }
> > > >
> > > > This code is valid, so long as the functions are never
called.
> > > >
> > > > I believe C++ requires that all functions have a distinct
address
> (ie:
> > > > &f1 != &f2) and LLVM optimizes code on this basis
(assert(f1 == f2)
> > > > gets optimized into an unconditional assertion failure)
> > > >
> > > > But these zero length functions can end up with identical
addresses.
> > > >
> > > > I'm unaware of anything in the C++ spec (or the LLVM
langref) that
> > > > would indicate that would allow distinct functions to have
identical
> > > > addresses - so should we do something about this in the LLVM
> backend?
> > > > add a little padding? a nop instruction? (if we're
adding an
> > > > instruction anyway, perhaps we might as well make it an
int3?)
> > > >
> > > > (I came across this due to DWARF issues with zero length
functions &
> > > > thinking about if/how this should be supported)
> > > > _______________________________________________
> > > > cfe-dev mailing list
> > > > cfe-dev at lists.llvm.org
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev