@kcc
I tried Ctrl-Cing out of fork mode on Linux with this patch.
The temp directories seemed to get cleaned up anyway.

In D58676#1410659, @hans wrote:

lgtm

I don't think committing to the branch works from the monorepo, so either check out the branch with svn (svn co https://llvm.org/svn/llvm-project/llvm/branches/release_80/docs/), or let me know and I'll commit for you.

Please take a look @hans
Please let me know if I'm mistakenly adding this to master.
Thanks!

• be more specific

Run clang-format-diff

Please take a look.
It might be worth adding -Wextra-semi to libFuzzer's cflags,.

Since Ctrl-C doesn't quite work in fork mode on Linux, I don't think this should block Windows.

• Fix race so that max_total_time works with fork mode and improve error messages.

I'm not sure this should be landed yet since IterateDirRecursive treats edge-case as a file.
I suspect that is harmless, but ideally it wouldn't do this.

• fail gracefully

In D58513#1406402, @zturner wrote:

In D58513#1406398, @metzman wrote:

In D58513#1406388, @zturner wrote:

Can you try mountvol <PATH>\mount C:\ and see what you print in this case?

This seems to break:

File: <PATH>\test-dir\dir\file-symlink2
File: <PATH>\test-dir\dir\y.txt
Dir: <PATH>\test-dir\dir
File: <PATH>\test-dir\dir-junction\file-symlink2
File: <PATH>\test-dir\dir-junction\y.txt
Dir: <PATH>\test-dir\dir-junction
File: <PATH>\test-dir\dir-Shortcut.lnk
File: <PATH>\test-dir\dir-symlink\file-symlink2
File: <PATH>\test-dir\dir-symlink\y.txt
Dir: <PATH>\test-dir\dir-symlink
File: <PATH>\test-dir\edge-case
File: <PATH>\test-dir\file-hardlink1
File: <PATH>\test-dir\file-hardlink2
File: <PATH>\test-dir\file-symlink
File: <PATH>\test-dir\file.txt
FindFirstFileA failed with error 5 for directory: <PATH>\ss64\$Recycle.Bin\blah; exiting

I'm not sure what the correct behavior in this case is though.

Actually just use a different directory then. Like mount D: instead of C:. Recycle bin is protected, so you probably won't be able to get directly into it without special permissions.

What I'm really wondering about is whether a volume mounted with mountvol will fall into your directory branch or your file branch. It should go into your directory branch.

In D58513#1406388, @zturner wrote:

Can you try mountvol <PATH>\mount C:\ and see what you print in this case?

I'm not sure this should be landed yet since IterateDirRecursive treats edge-case as a file.
I suspect that is harmless, but ideally it wouldn't do this.

• undo accidental linespace changes

• fix
• remove comment
• remove comment and simplify

• format

• fix
• Format and fix issue with /dev/null
• fix

For the record, I'm also fixing an issue with /dev/null being used on Win even though it doesn't work.

This patch wasn't quite ready for review but it looks like the comments were very useful. Thanks everyone!
Zach: I'll try to address your comments about links soon.

• more consistency

• Better comments

In D57597#1394411, @hans wrote:

In D57597#1394264, @Dor1s wrote:

You may need to use double backticks to put something into monospaced font, see https://reviews.llvm.org/rL352890. Maybe that's why the docs are still not updated.

Added that in r353809.

Merged this to the release_80 branch in r353811.

In D57597#1394264, @Dor1s wrote:

You may need to use double backticks to put something into monospaced font, see https://reviews.llvm.org/rL352890. Maybe that's why the docs are still not updated.

• make it clearer that we wont support incremental linking

Kostya asked me offline to change the sentence about clang 8 to say what revision support was added in before landing.

• mention /INCREMENTAL can't be used.

• Make Kostya's suggested change

In D57597#1381689, @metzman wrote:

In D57597#1381683, @rnk wrote:

In D57597#1381590, @rnk wrote:

In D57597#1381064, @kcc wrote:

any reliable bot will do.
This one, ... hm, doesn't seem reliable.
Last build passed two days ago :(
A separate bot would be nice if you expect a high rate of changes (and breakages) on windows

I am taking steps to add it to sanitizer-windows here, which is super fast and reliable (for a sanitizer bot =P):
http://lab.llvm.org:8011/builders/sanitizer-windows

To follow-up, check-fuzzer passed on sanitizer-windows:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/41419

[99/102] Running Fuzzer unit tests
llvm-lit.py: C:/b/slave/sanitizer-windows/build/llvm.src/projects/compiler-rt/test/fuzzer/lit.cfg:32: note: lsan feature unavailable
llvm-lit.py: C:/b/slave/sanitizer-windows/build/llvm.src/projects/compiler-rt/test/fuzzer/lit.cfg:39: note: msan feature unavailable
llvm-lit.py: C:/b/slave/sanitizer-windows/build/llvm.src/projects/compiler-rt/test/fuzzer/lit.cfg:57: note: linux feature unavailable
-- Testing: 36 tests, 16 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 0.92s
  Expected Passes    : 36

Do we need more targets?

check-fuzzer is the only target but it seems like only the unittests are running.

In D57597#1381683, @rnk wrote:

In D57597#1381590, @rnk wrote:

In D57597#1381064, @kcc wrote:

any reliable bot will do.
This one, ... hm, doesn't seem reliable.
Last build passed two days ago :(
A separate bot would be nice if you expect a high rate of changes (and breakages) on windows

I am taking steps to add it to sanitizer-windows here, which is super fast and reliable (for a sanitizer bot =P):
http://lab.llvm.org:8011/builders/sanitizer-windows

To follow-up, check-fuzzer passed on sanitizer-windows:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/41419

[99/102] Running Fuzzer unit tests
llvm-lit.py: C:/b/slave/sanitizer-windows/build/llvm.src/projects/compiler-rt/test/fuzzer/lit.cfg:32: note: lsan feature unavailable
llvm-lit.py: C:/b/slave/sanitizer-windows/build/llvm.src/projects/compiler-rt/test/fuzzer/lit.cfg:39: note: msan feature unavailable
llvm-lit.py: C:/b/slave/sanitizer-windows/build/llvm.src/projects/compiler-rt/test/fuzzer/lit.cfg:57: note: linux feature unavailable
-- Testing: 36 tests, 16 threads --
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
Testing Time: 0.92s
  Expected Passes    : 36

Do we need more targets?

In D57597#1381039, @kcc wrote:

do we have the bot?

I think libFuzzer on Windows is solid enough now to make public.
What do you think?

• mention support may be added

@vitalybuka
Please take a look at this trivial change.

@morehouse
Please take a look when you get a chance.
All of these tests pass on Win without takinn long.
I'd like to reenable them.

Please take a look.

• add comment

• add comment

commit message

• fmt

Please take a look.
This fixes the deprecated-instrumentation.test which is currently failing on Windows because the message doesn't print.
It doesn't print because OutputFile in FuzzerIO.cpp is not yet initialized when WarnAboutDeprecatedInstrumentation is called.
An alternative to this fix is just disabling the test on Windows, I don't worry much about the message not being printed because I don't think anyone has ever used trace-pc on Win with libFuzzer.

• check if _WIN32 is defined

In D57308#1373797, @morehouse wrote:

What was the original motivation for adding the extra stats?

Sorry @jfb, I don't need your review for this but phabricator keeps fighting me when I try to remove you.

Matt could you please take a look.
This patch removes an unused and complicated feature in afl_driver.cpp.

Please take a look.
This change silences a warning when compiling libFuzzer for Windows with clang.
It shouldn't affect anything other than compiling libFuzzer with clang on Windows.

Don't use default visibility with clang on Windows