In D52119#1237797, @rnk wrote:

I think we need to back up and think about what we're doing where and why.

If the application were fully statically linked, we wouldn't need to do anything in instrumentation code at all, we could just reference __start_*/__stop_* directly from the libfuzzer runtime, and that would contain all of sanitizer coverage data. The reason we have these module constructor calls is to deal with the case where the application is composed of multiple DSOs/DLLs. Each DSO will contain its own guards, counters, and pc arrays, and we can't arrange for them all to be contiguous.

• Remove unused file.

@rnk what do you think of this?
This change does cause many constructor calls to happen (thousands of times for some fuzzers) but there doesn't seem to be a problem with this as libFuzzer ignores the redundant calls.
Also, I'm not worried about a performance penalty from the redundant calls since they are cheap and only happen on program startup.

Should I remove FuzzerExtFunctionsDlsymWin.cpp?
I'm unsure about doing so because in Marcos's patch he didn't remove FuzzerExtFunctionsWeakAlias.cpp and because I may find how use it properly later, in which case removing it might make the history uglier?

@morehouse and @rnk: please take a look.

@morehouse @rnk
Please take a look.
This patch allows libFuzzer targets to be compiled with /OPT:REF and adds a test to ensure this.

• fix spacing

• Improve comments.
• Add test to compiler-rt

• remove extra whitespace.
• use target triple

Max could you please take a look when you get a chance (no rush).

• Make comment more descriptive

Matt, please take a look when you get a chance (no rush).

• undo accidental change

• Remove /Z7 flag.

In D51735#1226001, @Dor1s wrote:

I wonder if there is any trick in lit to resolve this .exe issue.

Please take a look.
Another issue with the file extension.
These issues aren't trivial to figure out, I wonder if all tests should compile binaries with exe extensions so problems aren't accidentally introduced.

Please take a look.

In my newest diff, we enter the if-body if argv0 was set by LLVMFuzzerInitialize and Data begins with "fuzz", which should be easy enough for most any test to pass.

• use different comparison and check pointer is not null

My first diff did an exact match on part of argv[0], doing the entire thing was too difficult: https://reviews.llvm.org/D51692?vs=on&id=164071&whitespace=ignore-most#toc
Do you think that solution is better than testing if argv0 was set?

Sorry, Matt you had a better understanding of what my patch does than I did.
You are right that the if-body is taken when the lengths are the same but the string is not different.
In any case though, I think testing if we can match strings is unnecessary anyway right? Can we just test that argv0 was set?

In D51692#1225180, @morehouse wrote:

That patch broke the behavior of this test. Looks like we used to print "BINGO" when the input matched the binary name. Now we print "BINGO" when the input size matches but the names do not.

Actually, I think I know why.
It looks like exact match was too difficult for LF (was lit not always used for tests?).
This is why a search function was first added by @george.karpenkov
See
https://github.com/llvm-mirror/llvm/commit/6795f26af554ad58aaca056db03657653b2e4e60#diff-1034b931b86661aee0b11db45658a8b5

In D51692#1225110, @morehouse wrote:

Maybe memcmp would be cleaner here.

@morehouse
Please take a look.
This patch replaces use of memmem with strstr so that the two tests that use this code can compile on Windows (they still fail because LLVMFuzzerInitialize isn't working, but I have a fix for that, patch on the way).

• remove comment

Replace memmem with strstr

cc @morehouse

• nfc: fix comments.
• Disable print_unstable_stats

• fix comment

Please take a look Matt.
This enables libfuzzer tests on windows, gets most of them to work, and disables about 20 tests as well (some temporarily, some permanently).

• update comments
• fix typo

update comments

• Port libFuzzer to Windows

LGTM

Trivial NFC to use local variable instead of accessing attribute twice.

Fix failing assertions by using CreateGEP instead of CreateAdd to add to a pointer.

Improve comments.

Improve comment

In D51022#1215225, @morehouse wrote:

We will need to disable failing tests for Windows. libFuzzer does run as part of check-all now.

Disable libFuzzer tests on Windows.

Thank you @rnk and @morehouse for your reviews.

Merge SCOVP section with .rdata

run clang format.

Merge guard and counter sections with .data section.
Also add better comments.

Undo unnecessary change to unittests.

Fix BaseName to handle '/' and '\' on Windows.

@rnk thank you for the feedback.
I will fix the issues you have raised shortly, but I have some questions on the feedback you left.

Reid could you please take a look.
This patch gets libFuzzer working on Windows.
Most functionality seems to work, a few features are not yet supported and the tests don't yet work. I plan on fixing these issues soon.