<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 17, 2018 at 12:43 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think that once this functionality is exposed via lli/LLJIT it would be reasonable to have a regression test to verify that a bad object files trigger an error from the tool code.</div></blockquote><div><br>So this is currently unreachable code? Could it remain an assertion, then, until it's added - so there's no chance of this slipping through untested? (this is generally the preferred approach in LLVM, I think - not adding unreachable/untestable code)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> This will be a New Thing for JIT API testing though: MCJIT and ORCv1 both notionally deal with bad object files, but never had tests for them. I assume it was just an aversion to checking in binary object-files for tests, but in this case we could just test with an empty object file.</div></blockquote><div><br>There are a few projects/areas of LLVM that contend with that htese days - for instance I think lld's approach is to rely on llvm-mc to assemble assembly-written test cases into object files to then pass into the linker for testing. Other areas (like llvm-dwarfdump) have some checked in binary object files. I'm undecided on the best approach here - certainly open to throwing around more ideas in that space.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br><div><div>-- Lang.</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 2:19 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 16, 2018 at 11:37 AM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm not sure this particular case deserves a test case. Prior to the change, passing a valid object was a matter of contract.</div></blockquote><div><br>Seems to me a test case demonstrating that the program behaves as expected when an invalid object is passed, now that that's a valid use-case is merited. Usual sort of LLVM test approach.<br><br>Whether it's a unit test or an end-to-end test I don't have strong feelings about.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"> After the change it is a trivial error-propagation, and we don't usually test them at every level of the stack.<div><div><br></div><div>I would like to see more "bad object" tests for libObject itself, but that's outside the scope of this patch.</div></div></div><div dir="ltr"><div><div><br></div><div>-- Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 6, 2018 at 8:47 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Test case?</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Aug 5, 2018 at 4:55 PM Lang Hames via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: lhames<br>
Date: Sun Aug 5 16:55:35 2018<br>
New Revision: 338975<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=338975&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=338975&view=rev</a><br>
Log:<br>
[ORC] Remove an incorrect use of 'cantFail'.<br>
<br>
This code was moved out from BasicObjectLayerMaterializationUnit, which required<br>
the supplied object to be well formed. The getObjectSymbolFlags function does<br>
not require a well-formed object, so we have to propagate the error here.<br>
<br>
Modified:<br>
llvm/trunk/lib/ExecutionEngine/Orc/Layer.cpp<br>
<br>
Modified: llvm/trunk/lib/ExecutionEngine/Orc/Layer.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/Orc/Layer.cpp?rev=338975&r1=338974&r2=338975&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/Orc/Layer.cpp?rev=338975&r1=338974&r2=338975&view=diff</a><br>
==============================================================================<br>
--- llvm/trunk/lib/ExecutionEngine/Orc/Layer.cpp (original)<br>
+++ llvm/trunk/lib/ExecutionEngine/Orc/Layer.cpp Sun Aug 5 16:55:35 2018<br>
@@ -116,8 +116,10 @@ Expected<SymbolFlagsMap> getObjectSymbol<br>
for (auto &Sym : (*Obj)->symbols()) {<br>
if (!(Sym.getFlags() & object::BasicSymbolRef::SF_Undefined) &&<br>
(Sym.getFlags() & object::BasicSymbolRef::SF_Exported)) {<br>
- auto InternedName =<br>
- ES.getSymbolStringPool().intern(cantFail(Sym.getName()));<br>
+ auto Name = Sym.getName();<br>
+ if (!Name)<br>
+ return Name.takeError();<br>
+ auto InternedName = ES.getSymbolStringPool().intern(*Name);<br>
auto SymFlags = JITSymbolFlags::fromObjectSymbol(Sym);<br>
if (!SymFlags)<br>
return SymFlags.takeError();<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>