[lld] r259596 - ELF: Do not exit if it cannot open an output
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 3 09:25:45 PST 2016
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>
> +# 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
> 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
> Do you think this approach can be used as fix or there can be better
> solution ?
> Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits