<div dir="ltr">Ok, I'll submit a patch to turn that into a report_fatal_error saying you can't start an abbrev with an array or blob.<div><br></div><div>Thanks,</div><div><br></div><div>  Filipe</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">  F<br></div></div>
<br><div class="gmail_quote">On Fri, Jan 23, 2015 at 2:12 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The restriction looks reasonable: A record starts with a code. The code can be encoded as a literal or be part of the abbreviation.<div><br></div><div>There is probably not a lot of value in supporting a code embedded in the first element of an array or blob. </div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 23 January 2015 at 16:47, Filipe Cabecinhas <span dir="ltr"><<a href="mailto:filcab@gmail.com" target="_blank">filcab@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi all!<div><br></div><div>Fuzzing llvm's bitcode reader, I found a problem where the reader assumes that the first field in an abbreviation will not be an array or a blob (and asserts otherwise).</div><div><br></div><div>I don't know if this is expected (but not documented) or not. The documentation, to me, reads like it doesn't disallow it, but we might be assuming all abreviations start with a full record, which would make the first operand never be an array or a blob.</div><div><br></div><div>The bug comes from r181639 (<a href="http://llvm.org/klaus/llvm/commit/1197e38f3338b8db76f0fa38c2687c65b2bcea5c/" target="_blank">http://llvm.org/klaus/llvm/commit/1197e38f3338b8db76f0fa38c2687c65b2bcea5c/</a>), which took the code to read the first argument and put it outside of the loop, but didn't take the Array/Blob verification + reading code too (It's a bug because that commit was supposed to not have changed functionality :-) ).</div><div><br></div><div>This could be “fixed” with, either a report_fatal_error (if we eventually have better error handling on that code, we can make that non-fatal and report to the caller), or by hoisting the Array/Blob reading code out of the loop too (actually, write a helper function).</div><div><br></div><div>What should be done about this?</div><div><br></div><div>Thanks,</div><div><br clear="all"><div><div>  Filipe<br></div></div>
</div></div>
</div><br></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>