[llvm] r199835 - Eliminate inappropriate use of FindProgramByName() from lli

[Alp Toker]

On 23/01/2014 06:24, Chandler Carruth wrote:
>
> On Wed, Jan 22, 2014 at 10:07 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>     Hi Nick,
>
>     lli-child-target is more like a test input that happens to also be
>     a byproduct of the build system. As such I've tested it the same
>     way we test plugins using the corresponding %shlibext substitution.
>
>     The fact it's built with add_llvm_tool() and links in the whole of
>     LLVM appears is just another bug that needs fixing so I'd
>     certainly avoid giving it a substitution the we do for actual
>     installed tools like %clang or %lli. Does that make sense to you?
>
>
> Personally, I find the design of just doing whole-file-name 
> substitution simpler to reason about than substituting file 
> extensions. (I feel the same way about %shlibext, but honestly hadn't 
> noticed it.)
>
> It's not a big deal either way, but all things being equal it seems 
> more consistent to just substitute the file name. :: shrug ::
>

Right. I think it's worth keeping these tests similar to the plugin 
tests here because we're purposefully testing the behaviour of the 
commandline option and loader itself, whereas opaque commands like 
%clang or %lli just say "run this thing the way you see fit".

That means test coverage would ideally try with and without a qualified 
path, and on Windows with and without an exe suffix given that the 
Windows loader is perfectly happy to accept both forms.

I'd like to keep those testing options open because this is perhaps the 
one part of LLVM that's actually security-sensitive in so far as people 
will be directly building upon it to sandbox untrusted code on public 
servers.


>
> (FWIW, I agree that the remote jit stuff doesn't feel finished or well 
> engineered. It could definitely use some love...)

Yeah, to be clear the rant wasn't directed at specific individuals, more 
a failing of the project as a whole. It's more fun and productive when 
we all hold ourselves to the same high standards as we expect from third 
party patch contributors. The silver lining though is that remote MCJIT 
is quite a neat concept and a few people are giving up their time now to 
see if they can turn the implementation around :-)

Alp.


-- 
http://www.nuanti.com
the browser experts