<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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;}
--></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">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Where is the testing that proves all this works? Patches welcome…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Now, I've known QA people who break software in two minutes as naturally as breathing; I do not have that skill. Given that I came up with *anything* in two
minutes, I am not filled with confidence.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Right now I'm in the middle of un-borking my bots in the wake of the upstream "improvements" to GetSVN.cmake, but I will see what else I can do.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></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 #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Sean Silva [mailto:chisophugis@gmail.com]
<br>
<b>Sent:</b> Tuesday, November 25, 2014 2:38 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Yung, Douglas; llvmdev@cs.uiuc.edu; Reid Kleckner; Bruce Hoult<br>
<b>Subject:</b> RE: [LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><br>
On Nov 25, 2014 11:59 AM, "Robinson, Paul" <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>> wrote:<br>
><br>
> The fundamental problem is that IR has never been treated as "user input" before. It has always been an ephemeral format, and if some component comes along and sees something it doesn't recognize, that is ipso facto a compiler bug, not a user input error,
and it's perfectly okay to crash on a compiler bug. Changing that fundamental assumption would be pretty pervasive.<o:p></o:p></p>
<p>Sorry, but this is at variance to my experience. In my experience, the fundamental assumption is that we should never crash on bad user input. And LLVM as a library definitely considers bitcode as "user input".<o:p></o:p></p>
<p>Of course, -disable-verify and similar voids that warranty.<o:p></o:p></p>
<p>><br>
> <br>
><br>
> I will say that the bitcode reader itself is pretty good about identifying bitcode it doesn't recognize; it's the components deeper inside LLVM that are more worrisome.<o:p></o:p></p>
<p>Could you give a couple examples? It sounds like you are talking about a systemic problem, but so far only one example has been presented.<o:p></o:p></p>
<p>-- Sean Silva<o:p></o:p></p>
<p>><br>
> --paulr<br>
><br>
> <br>
><br>
> From: Reid Kleckner [mailto:<a href="mailto:rnk@google.com">rnk@google.com</a>]
<br>
> Sent: Tuesday, November 25, 2014 11:43 AM<br>
> To: Sean Silva<br>
> Cc: Robinson, Paul; Bruce Hoult; <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>; Yung, Douglas<br>
><br>
> Subject: Re: [LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)<br>
><br>
> <br>
><br>
> On Mon, Nov 24, 2014 at 9:41 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
>><br>
>> I fail to see why all that re-engineering effort IS "required" to support the use-cases we've provided, and why future-proofing a large body of software that quite honestly was never designed for it and has genuinely very few reasons why it should be.<br>
>><br>
>> <br>
>><br>
>> If we're going to support bitcode as a long-term storage format, everything that pulls information out of bitcode MUST be future-proofed. Doing it piece by piece is a LOT of engineering effort to make LLVM user-friendly in this way; it was never intended
to have that degree of self-defense.<br>
><br>
> <br>
><br>
> I don't understand what you mean by "future-proofed" in this context. If you mean "never crash on bad user input", then your point doesn't make sense to me. LLVM is engineered to never crash on bad user input in the same sense that it is engineered to correctly
compile code; neither is allowed, and if either happens it is a bug.<br>
><br>
> <br>
><br>
> This is true, but we can say from experience that there are a lot of these kinds of bugs and it will take a lot of effort to fix them all. Personally, I think this worth doing. We should be using the new diagnostic handler on the LLVMContext, and most of
LLVM should have a way of returning without exploding.<o:p></o:p></p>
</div>
</div>
</body>
</html>