The best option is to get a .bc file with the elements you need (but a correct file).<div>What tends to happen is that you get abbreviations for most things. Then you pause the reader on some line a bit before reading the thing you want. Then look at the abbrev table and the abbrev you're reading, make sure they match and note the offset in bits.</div><div>Then it's time to hex edit the file to change the abbrev at the point you want (the instruction's MDNode) to instead point to the MDString.</div><div><br></div><div>Let me know if you need further help. I'll try to reproduce that problem, but probably only tomorrow, if I can.</div><div><br></div><div>  Filipe <br>On Tuesday, 15 March 2016, Justin Bogner via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I hit a crash in the bitcode reader on some corrupt input where an<br>
MDString had somehow been attached to an instruction instead of an<br>
MDNode. This input is pretty bogus, but we shouldn't be crashing on bad<br>
input here.<br>
<br>
The attached patch adds error handling in all of the places where we<br>
currently have unchecked casts from Metadata to MDNode, which means<br>
we'll error out instead of crashing for that sort of input.<br>
<br>
Unfortunately, I can't figure out a way to write a test to hit these<br>
corner cases. Tips on generating bogus bitcode would be welcome.<br>
<br>
</blockquote></div>