• fix comment

@morehouse I added a test for this. Please take another look.

• Use echo instead of printf

• Add test

In D54180#1289406, @Dor1s wrote:

I guess it might be worth adding the binary mode argument to FuzzerMerge.cpp and FuzzerDataFlowTrace.cpp as well, since apparently we may have some unexpected platform-dependent specifics when reading files.

Please take a look

• Fix binary issue afl_driver

Matt, could you please take a look at this trivial change.

Please take a look at this NFC.
It merges code from the two places where we were getting section start and end pointers.
Though @kcc only asked for merging the code handling the start pointers on Windows, I decided to combine other nearby duplicated code.

• Add support for i386.

@rnk
Please take another look.

• clang-format

• clang-format

• Improve comment.
• Add test to compiler-rt
• improve comment
• fix spacing
• Use COMDAT but force include of constructors and give them weak ODR linking

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 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