| Message ID | 20170925142648.25959-7-george.dunlap@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 25.09.17 at 16:26, <george.dunlap@citrix.com> wrote: > --- a/tools/fuzz/README.afl > +++ b/tools/fuzz/README.afl > @@ -41,3 +41,17 @@ Use the x86 instruction emulator fuzzer as an example. > $ $AFLPATH/afl-fuzz -t 1000 -i testcase_dir -o findings_dir -- ./afl-harness > > Please see AFL documentation for more information. > + > +# GENERATING COVERAGE INFORMATION > + > +To use afl-cov or gcov, you need a separate binary instrumented to > +generate coverage data. To do this, use the target `afl-cov`: > + > + $ make afl-cov #produces afl-harness-cov > + > +NOTE: Please also note that the coverage instrumentation hard-codes > +the absolute path for the instrumentation read and write files in the > +binary; so coverage data will always show up in the build directory no > +matter where you run the binary from. > + > +Please see afl-cov and/or gcov documentation for more information. > \ No newline at end of file Would you please add the missing newline? > --- a/tools/fuzz/x86_instruction_emulator/Makefile > +++ b/tools/fuzz/x86_instruction_emulator/Makefile > @@ -23,19 +23,34 @@ x86_emulate_user.c x86_emulate_user.h: %: > > CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I. > > +GCOV_FLAGS=--coverage := ? > x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h > x86_emulate.h := x86_emulate_user.h x86_emulate/x86_emulate.h $(x86.h) > > -x86_emulate_user.o: x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) > +X86_EMULATE_INPUTS = x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) > +x86_emulate_user.o: $(X86_EMULATE_INPUTS) > + > +x86_emulate_user-cov.o: $(X86_EMULATE_INPUTS) > + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ x86_emulate_user.c > > fuzz-emul.o: $(x86_emulate.h) > > +fuzz-emul-cov.o: fuzz-emul.c $(x86_emulate.h) > + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ fuzz-emul.c > + > +afl-harness-cov.o: afl-harness.c > + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) $^ -o $@ Rather than effectively repeating this command three time, I think someone else had already suggested to use a pattern rule instead. > @@ -46,7 +61,7 @@ distclean: clean > > .PHONY: clean > clean: > - rm -f *.a *.o .*.d afl-harness > + rm -f *.a *.o .*.d afl-harness afl-harness-cov *.gcda *.gcno *.gcov Perhaps simply *.gc* to cover for possible future generated file types? Jan
On 10/04/2017 09:23 AM, Jan Beulich wrote: >>>> On 25.09.17 at 16:26, <george.dunlap@citrix.com> wrote: >> --- a/tools/fuzz/README.afl >> +++ b/tools/fuzz/README.afl >> @@ -41,3 +41,17 @@ Use the x86 instruction emulator fuzzer as an example. >> $ $AFLPATH/afl-fuzz -t 1000 -i testcase_dir -o findings_dir -- ./afl-harness >> >> Please see AFL documentation for more information. >> + >> +# GENERATING COVERAGE INFORMATION >> + >> +To use afl-cov or gcov, you need a separate binary instrumented to >> +generate coverage data. To do this, use the target `afl-cov`: >> + >> + $ make afl-cov #produces afl-harness-cov >> + >> +NOTE: Please also note that the coverage instrumentation hard-codes >> +the absolute path for the instrumentation read and write files in the >> +binary; so coverage data will always show up in the build directory no >> +matter where you run the binary from. >> + >> +Please see afl-cov and/or gcov documentation for more information. >> \ No newline at end of file > > Would you please add the missing newline? Ack > >> --- a/tools/fuzz/x86_instruction_emulator/Makefile >> +++ b/tools/fuzz/x86_instruction_emulator/Makefile >> @@ -23,19 +23,34 @@ x86_emulate_user.c x86_emulate_user.h: %: >> >> CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I. >> >> +GCOV_FLAGS=--coverage > > := ? Ack > >> x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h >> x86_emulate.h := x86_emulate_user.h x86_emulate/x86_emulate.h $(x86.h) >> >> -x86_emulate_user.o: x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) >> +X86_EMULATE_INPUTS = x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) >> +x86_emulate_user.o: $(X86_EMULATE_INPUTS) >> + >> +x86_emulate_user-cov.o: $(X86_EMULATE_INPUTS) >> + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ x86_emulate_user.c >> >> fuzz-emul.o: $(x86_emulate.h) >> >> +fuzz-emul-cov.o: fuzz-emul.c $(x86_emulate.h) >> + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ fuzz-emul.c >> + >> +afl-harness-cov.o: afl-harness.c >> + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) $^ -o $@ > > Rather than effectively repeating this command three time, I think > someone else had already suggested to use a pattern rule instead. What do you mean "three times"? There's only one *-cov.o file which can possibly be created by a generic rule, and that's this one. (The others all have special formulas already.) Is it really worth making a generic rule for a single instance? >> @@ -46,7 +61,7 @@ distclean: clean >> >> .PHONY: clean >> clean: >> - rm -f *.a *.o .*.d afl-harness >> + rm -f *.a *.o .*.d afl-harness afl-harness-cov *.gcda *.gcno *.gcov > > Perhaps simply *.gc* to cover for possible future generated file types? If I knew that this wouldn't match files like "foo.gcov-notes.txt" I'd be fine with it. I'll change it if you insist but I think it's probably better the way it is for now. -George
>>> On 04.10.17 at 18:48, <george.dunlap@citrix.com> wrote: > On 10/04/2017 09:23 AM, Jan Beulich wrote: >>>>> On 25.09.17 at 16:26, <george.dunlap@citrix.com> wrote: >>> x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h >>> x86_emulate.h := x86_emulate_user.h x86_emulate/x86_emulate.h $(x86.h) >>> >>> -x86_emulate_user.o: x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) >>> +X86_EMULATE_INPUTS = x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) >>> +x86_emulate_user.o: $(X86_EMULATE_INPUTS) >>> + >>> +x86_emulate_user-cov.o: $(X86_EMULATE_INPUTS) >>> + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ x86_emulate_user.c >>> >>> fuzz-emul.o: $(x86_emulate.h) >>> >>> +fuzz-emul-cov.o: fuzz-emul.c $(x86_emulate.h) >>> + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ fuzz-emul.c >>> + >>> +afl-harness-cov.o: afl-harness.c >>> + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) $^ -o $@ >> >> Rather than effectively repeating this command three time, I think >> someone else had already suggested to use a pattern rule instead. > > What do you mean "three times"? There's only one *-cov.o file which > can possibly be created by a generic rule, and that's this one. (The > others all have special formulas already.) Is it really worth making a > generic rule for a single instance? All three rules could be changed to use $< afaict, and then they're all identical. >>> @@ -46,7 +61,7 @@ distclean: clean >>> >>> .PHONY: clean >>> clean: >>> - rm -f *.a *.o .*.d afl-harness >>> + rm -f *.a *.o .*.d afl-harness afl-harness-cov *.gcda *.gcno *.gcov >> >> Perhaps simply *.gc* to cover for possible future generated file types? > > If I knew that this wouldn't match files like "foo.gcov-notes.txt" I'd > be fine with it. I'll change it if you insist but I think it's probably > better the way it is for now. Okay, same matter of taste as in the earlier patch. I.e. no, I won't insist. Jan
diff --git a/.gitignore b/.gitignore index cc16649457..5c8ed26b87 100644 --- a/.gitignore +++ b/.gitignore @@ -162,6 +162,7 @@ tools/fuzz/libelf/afl-libelf-fuzzer tools/fuzz/x86_instruction_emulator/asm tools/fuzz/x86_instruction_emulator/x86_emulate* tools/fuzz/x86_instruction_emulator/afl-harness +tools/fuzz/x86_instruction_emulator/afl-harness-cov tools/helpers/_paths.h tools/helpers/init-xenstore-domain tools/helpers/xen-init-dom0 diff --git a/tools/fuzz/README.afl b/tools/fuzz/README.afl index 4758de2490..0d955b2687 100644 --- a/tools/fuzz/README.afl +++ b/tools/fuzz/README.afl @@ -41,3 +41,17 @@ Use the x86 instruction emulator fuzzer as an example. $ $AFLPATH/afl-fuzz -t 1000 -i testcase_dir -o findings_dir -- ./afl-harness Please see AFL documentation for more information. + +# GENERATING COVERAGE INFORMATION + +To use afl-cov or gcov, you need a separate binary instrumented to +generate coverage data. To do this, use the target `afl-cov`: + + $ make afl-cov #produces afl-harness-cov + +NOTE: Please also note that the coverage instrumentation hard-codes +the absolute path for the instrumentation read and write files in the +binary; so coverage data will always show up in the build directory no +matter where you run the binary from. + +Please see afl-cov and/or gcov documentation for more information. \ No newline at end of file diff --git a/tools/fuzz/x86_instruction_emulator/Makefile b/tools/fuzz/x86_instruction_emulator/Makefile index 10009dc08f..4e829dfcbc 100644 --- a/tools/fuzz/x86_instruction_emulator/Makefile +++ b/tools/fuzz/x86_instruction_emulator/Makefile @@ -23,19 +23,34 @@ x86_emulate_user.c x86_emulate_user.h: %: CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -I. +GCOV_FLAGS=--coverage + x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h x86_emulate.h := x86_emulate_user.h x86_emulate/x86_emulate.h $(x86.h) -x86_emulate_user.o: x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) +X86_EMULATE_INPUTS = x86_emulate_user.c x86_emulate/x86_emulate.c $(x86_emulate.h) +x86_emulate_user.o: $(X86_EMULATE_INPUTS) + +x86_emulate_user-cov.o: $(X86_EMULATE_INPUTS) + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ x86_emulate_user.c fuzz-emul.o: $(x86_emulate.h) +fuzz-emul-cov.o: fuzz-emul.c $(x86_emulate.h) + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) -o $@ fuzz-emul.c + +afl-harness-cov.o: afl-harness.c + $(CC) -c $(CFLAGS) $(GCOV_FLAGS) $^ -o $@ + x86-insn-fuzzer.a: fuzz-emul.o x86_emulate_user.o $(AR) rc $@ $^ afl-harness: afl-harness.o fuzz-emul.o x86_emulate_user.o $(CC) $(CFLAGS) $^ -o $@ +afl-harness-cov: afl-harness-cov.o fuzz-emul-cov.o x86_emulate_user-cov.o + $(CC) $(CFLAGS) $(GCOV_FLAGS) $^ -o $@ + # Common targets .PHONY: all all: x86-insn-fuzz-all @@ -46,7 +61,7 @@ distclean: clean .PHONY: clean clean: - rm -f *.a *.o .*.d afl-harness + rm -f *.a *.o .*.d afl-harness afl-harness-cov *.gcda *.gcno *.gcov .PHONY: install install: all @@ -55,3 +70,6 @@ install: all .PHONY: afl afl: afl-harness + +.PHONY: afl-cov +afl-cov: afl-harness-cov
...to generate a "normal" coverage-instrumented binary, suitable for use with gcov or afl-cov. This is slightly annoying because: - Every object file needs to have been instrumented to work effectively - You generally want to have both an afl-instrumented binary and a gcov-instrumented binary at the same time, but - gcov instrumentation and afl instrumentation are mutually exclusive So when making the `afl-cov` target, generate a second set of object files and a second binary with the `-cov` suffix. Signed-off-by: George Dunlap <george.dunlap@citrix.com> --- Changes in v2: - Pull 'inputs' to x86_emulate_user* into a make variable to avoid duplication CC: Ian Jackson <ian.jackson@citrix.com> CC: Wei Liu <wei.liu2@citrix.com> CC: Andrew Cooper <andrew.cooper3@citrix.com> CC: Jan Beulich <jbeulich@suse.com> --- .gitignore | 1 + tools/fuzz/README.afl | 14 ++++++++++++++ tools/fuzz/x86_instruction_emulator/Makefile | 22 ++++++++++++++++++++-- 3 files changed, 35 insertions(+), 2 deletions(-)