<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:973368717;
mso-list-type:hybrid;
mso-list-template-ids:-50058494 2065067570 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-number-format:alpha-lower;
mso-level-text:"\(%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I’m not aware of anyone picking this up, but then I haven’t been watching for it.<o:p></o:p></p>
<p class="MsoNormal">LLVMTargetMachine supports a command-line “-trap-unreachable” so the Linux build could turn it on universally that way. Some targets already have it turned on, and are willing to take the (fairly small IIRC) size hit. Note that the flag
tends to be set in target-specific code but the effect is implemented in generic code, so it should Just Work. If Linux doesn’t like the size hit, then someone will have to implement one of the more targeted ideas, e.g., add a nop/trap only after the last
block of a function (ideally but not necessarily omitting that if the function ends with a ret or unconditional branch).<o:p></o:p></p>
<p class="MsoNormal">I’ll admit that Sony would benefit from the more targeted feature, as that’s the exact use-case we need, but we haven’t deemed the size cost of TrapUnreachable to be enough to warrant the additional effort.<o:p></o:p></p>
<p class="MsoNormal">--paulr<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Hans Wennborg <hans@chromium.org> <br>
<b>Sent:</b> Tuesday, September 7, 2021 8:24 AM<br>
<b>To:</b> David Blaikie <dblaikie@gmail.com>; Nick Desaulniers <ndesaulniers@google.com><br>
<b>Cc:</b> Robinson, Paul <paul.robinson@sony.com>; Clang Dev <cfe-dev@lists.llvm.org>; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [cfe-dev] Zero length function pointer equality<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Did anything come of this?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The Linux folks (cc Nick) keep running into issues where a function which ends with unreachable can fall through to an unrelated function, which confuses some machine code analyser they run (e.g. <a href="https://urldefense.com/v3/__https:/github.com/ClangBuiltLinux/linux/issues/1440__;!!JmoZiZGBv3RvKRSx!qYlbY1j6iDE6WGMU8OKnc3po09Ff8PvUduMgCzcCRcUv0ANZnBSJyDIWOhSKiqWzsg$">https://github.com/ClangBuiltLinux/linux/issues/1440</a>).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It seems TrapUnreachable would avoid such issues.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Mar 19, 2021 at 10:11 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Just writing it down in this thread - this issue's been discussed a bit in this bug: <a href="https://urldefense.com/v3/__https:/bugs.llvm.org/show_bug.cgi?id=49599__;!!JmoZiZGBv3RvKRSx!qYlbY1j6iDE6WGMU8OKnc3po09Ff8PvUduMgCzcCRcUv0ANZnBSJyDIWOhRT6p37JQ$" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=49599</a><br>
<br>
And yeah, I'm considering adopting MachO's default (TrapUnreachable + NoTrapOnNoreturn) as the default for LLVM (will require some design discussion, no doubt) since it seems to capture most of the functionality desired. Maybe there are some cases where we
have extra unreachables that could've otherwise been optimized away/elided, but hopefully nothing drastic.<br>
<br>
(some platforms still need the trap-on-noreturn - Windows+AArch64 and maybe Sony, etc - happy for some folks to opt into that). I wonder whether TrapUnreachable shouldn't even be an option anymore though, if it becomes load bearing for correctness - or should
it become a fallback option - "no trap unreachable" maybe means nop instead of trap, in case your target can't handle a trap sometimes (I came across an issue with AMDGPU not being able to add traps to functions that it isn't expecting - the function needs
some special attribute to have a trap in it - but I guess it can be updated to add that attribute if the function has an unreachable in it (though then it has to recreate the no-trap-on-noreturn handling too when deciding whether to add the attribute... ))<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jul 27, 2020 at 9:20 AM Robinson, Paul <<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
<br>
> -----Original Message-----<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Hans<br>
> Wennborg via llvm-dev<br>
> Sent: Monday, July 27, 2020 9:11 AM<br>
> To: David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] [cfe-dev] Zero length function pointer equality<br>
> <br>
> On Sat, Jul 25, 2020 at 3:40 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> ><br>
> > Looks perfect to me!<br>
> ><br>
> > well, a couple of questions: Why a noop, rather than int3/ud2/etc?<br>
> <br>
> Probably no reason.<br>
<br>
FTR there is TargetOptions.TrapUnreachable, which some targets turn on<br>
(for X86 it's on for MachO and PS4), this turns 'unreachable' into ud2.<br>
Clearly it covers more than "empty" functions but is probably the kind<br>
of thing you're looking for.<br>
--paulr<br>
<br>
> <br>
> > Might be worth using the existing code that places such an instruction<br>
> > when building at -O0?<br>
> <br>
> I wasn't aware of that. Does it happen for all functions (e.g. I think<br>
> I got pulled into this due to functions with the naked attribute)?<br>
> <br>
> > & you mention that this causes problems on Windows - but ICF done by<br>
> > the Windows linker does not cause such problems? (I'd have thought<br>
> > they'd result in the same situation - two functions described as being<br>
> > at the same address?) is there a quick summary of why those two cases<br>
> > turn out differently?<br>
> <br>
> The case that we hit was that the Control Flow Guard table of<br>
> addresses in the binary ended up listing the same address twice, which<br>
> the loader didn't expect. It may be that the linker took care to avoid<br>
> that for ICF (if two ICF'd functions got the same address, only list<br>
> it once in the CFG table) but still didn't handle the "empty function"<br>
> problem.<br>
> <br>
> > On Fri, Jul 24, 2020 at 6:17 AM Hans Wennborg <<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>> wrote:<br>
> > ><br>
> > > Maybe we can just expand this to always apply:<br>
> <a href="https://urldefense.com/v3/__https:/reviews.llvm.org/D32330__;!!JmoZiZGBv3RvKRSx!qYlbY1j6iDE6WGMU8OKnc3po09Ff8PvUduMgCzcCRcUv0ANZnBSJyDIWOhRnihf1DQ$" target="_blank">
https://reviews.llvm.org/D32330</a><br>
> > ><br>
> > > On Fri, Jul 24, 2020 at 2:46 AM David Blaikie via cfe-dev<br>
> > > <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
> > > ><br>
> > > > LLVM can produce zero length functions from cases like this (when<br>
> > > > optimizations are enabled):<br>
> > > ><br>
> > > > void f1() { __builtin_unreachable(); }<br>
> > > > int f2() { /* missing return statement */ }<br>
> > > ><br>
> > > > This code is valid, so long as the functions are never called.<br>
> > > ><br>
> > > > I believe C++ requires that all functions have a distinct address<br>
> (ie:<br>
> > > > &f1 != &f2) and LLVM optimizes code on this basis (assert(f1 == f2)<br>
> > > > gets optimized into an unconditional assertion failure)<br>
> > > ><br>
> > > > But these zero length functions can end up with identical addresses.<br>
> > > ><br>
> > > > I'm unaware of anything in the C++ spec (or the LLVM langref) that<br>
> > > > would indicate that would allow distinct functions to have identical<br>
> > > > addresses - so should we do something about this in the LLVM<br>
> backend?<br>
> > > > add a little padding? a nop instruction? (if we're adding an<br>
> > > > instruction anyway, perhaps we might as well make it an int3?)<br>
> > > ><br>
> > > > (I came across this due to DWARF issues with zero length functions &<br>
> > > > thinking about if/how this should be supported)<br>
> > > > _______________________________________________<br>
> > > > cfe-dev mailing list<br>
> > > > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> > > > <a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev__;!!JmoZiZGBv3RvKRSx!qYlbY1j6iDE6WGMU8OKnc3po09Ff8PvUduMgCzcCRcUv0ANZnBSJyDIWOhTTLrIurw$" target="_blank">
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!qYlbY1j6iDE6WGMU8OKnc3po09Ff8PvUduMgCzcCRcUv0ANZnBSJyDIWOhRPBWWW9A$" target="_blank">
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>