[lld] r259596 - ELF: Do not exit if it cannot open an output

[Rui Ueyama via llvm-commits]

I tried that locally but it succeeded for some reason. But yes, in general,
probably writing to /dev/null or nul was not a good idea. Let me change the
path so that it always guaranteed to fail.

On Wed, Feb 3, 2016 at 9:19 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
> +# RUN: not ld.lld %t -o /dev/null 2>&1 | FileCheck -check-prefix=CHECK2 %s
> +
> +# CHECK2: failed to open
>
> Hello Rui,
>
> This test fails for me (under windows).
>
> I attached debugger to see what happens during lld call when test runs and
> saw
> that instead of "/dev/null" Writer<ELFT>::openFile() =>
> FileOutputBuffer::create(StringRef FilePath, size_t Size, unsigned Flags)
> method is called with "c:\\users\\anon\\appdata\\local\\temp\\tmplzmikp"
> FilePath argument.
>
> And I traced to entrypoint main(int argc, const char *argv[]) and that
> temporary file was already in argv,
> and after some investigation I found that llvm\utils\lit\lit\TestRunner.py
> has next line:
>
> # Use temporary files to replace /dev/null on Windows.
> kAvoidDevNull = kIsWindows
>
> If I put kAvoidDevNull = 0 instead then test runs successfuly.
> I am not sure why windows buildbots are not failing now though.
>
> If I rename "/dev/null" to "/dev/null/dontreplacemeplz" in test thats also
> helps.
> Do you think this approach can be used as fix or there can be better
> solution ?
>
>
> Best regards,
> George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160203/ff65dfb1/attachment.html>