i#1734 drfuzz: add several fuzz options

Commit log for first patchset:
---------------
i#1734 drfuzz: add several fuzz options

- add several fuzz options, including:
  -fuzz, -fuzz_module, -fuzz_function, -fuzz_offset, -fuzz_num_args,
  -fuzz_data, -fuzz_size, and -fuzz_count
- rename fuzzer_fuzz_option_target to fuzzer_option_init and make it static
---------------

[bruening, 2015-11-06 03:57:48]

https://codereview.appspot.com/276780043/diff/1/drmemory/fuzzer.c
File drmemory/fuzzer.c (right):

https://codereview.appspot.com/276780043/diff/1/drmemory/fuzzer.c#newcode269
drmemory/fuzzer.c:269: fuzzer_fuzz_target(desc);
Wouldn't it be nicer to have drfuzz also take in separated options?  Why smoosh
everything here into a string and then have to parse it all on the other side
over a C function call interface where we could easily keep them separated?  Is
there a current or planned interface where we have to serialize everything into
a string for any reason?

[zhaoqin, 2015-11-06 04:33:04]

https://codereview.appspot.com/276780043/diff/1/drmemory/fuzzer.c
File drmemory/fuzzer.c (right):

https://codereview.appspot.com/276780043/diff/1/drmemory/fuzzer.c#newcode269
drmemory/fuzzer.c:269: fuzzer_fuzz_target(desc);
On 2015/11/06 03:57:47, bruening wrote:
> Wouldn't it be nicer to have drfuzz also take in separated options?  Why
smoosh
> everything here into a string and then have to parse it all on the other side
> over a C function call interface where we could easily keep them separated? 
Is
> there a current or planned interface where we have to serialize everything
into
> a string for any reason?

It is the easiest way to do so. The current implementation parse the compact
option.fuzz_target string and fill fuzz_target data structure, xref
user_input_parse_target.
We could implement a function to fill in the fuzz_target structure too, but it
also need match the behavior of user_input_parse_target.
Do we want to keep this compact option format?
If we keep it, we should either construct the string and then do the parsing
(what I did in this CL), or we first parse the string and fill the
options.fuzz_*, and then fill fuzz_target.

[bruening, 2015-11-06 04:42:26]

On 2015/11/06 04:33:04, zhaoqin wrote:
> Do we want to keep this compact option format?

The only reason I can think of is to support multiple function targets at once,
but would we prefer a config file rather than string options for that?

[zhaoqin, 2015-11-06 05:19:53]

On 2015/11/06 04:42:26, bruening wrote:
> On 2015/11/06 04:33:04, zhaoqin wrote:
> > Do we want to keep this compact option format?
> 
> The only reason I can think of is to support multiple function targets at
once,
> but would we prefer a config file rather than string options for that?

sure.
I was thinking of back-comparability, but since it is early, I guess we can
remove it. That would be a fairly large CL.

[Byron, 2015-11-06 07:28:22]

On 2015/11/06 05:19:53, zhaoqin wrote:
> On 2015/11/06 04:42:26, bruening wrote:
> > On 2015/11/06 04:33:04, zhaoqin wrote:
> > > Do we want to keep this compact option format?
> > 
> > The only reason I can think of is to support multiple function targets at
> once,
> > but would we prefer a config file rather than string options for that?
> 
> sure.
> I was thinking of back-comparability, but since it is early, I guess we can
> remove it. That would be a fairly large CL.

The original reason for using a compact format was to make it consistent with a
future file-based fuzz descriptor. I don't think there was any other reason for
it--except maybe for bash scripts, where the formatting works out a little nicer
if the inputs are not too verbose.

[zhaoqin, 2015-11-09 05:04:40]

Commit log for latest patchset:
---------------
i#1734 drfuzz: add several fuzz options

- add several fuzz options, including:
  -fuzz, -fuzz_module, -fuzz_function, -fuzz_offset, -fuzz_num_args,
  -fuzz_arg_data, -fuzz_arg_size, and -fuzz_count
- rename fuzzer_fuzz_option_target to fuzzer_option_init
- add fuzzer_fuzz_target_init
- extract fuzzer_fuzz_target_callconv_arg_init

Review-URL: https://codereview.appspot.com/276780043
---------------

[bruening, 2015-11-10 18:47:03]

LGTM w/ suggestions

https://codereview.appspot.com/276780043/diff/20001/drmemory/optionsx.h
File drmemory/optionsx.h (right):

https://codereview.appspot.com/276780043/diff/20001/drmemory/optionsx.h#newco...
drmemory/optionsx.h:600: # define FUZZ_FUNC_DEFAULT_NAME
"drmemory_fuzz_function"
In the slides you have "DrMFuzzerInput"???

https://codereview.appspot.com/276780043/diff/20001/drmemory/optionsx.h#newco...
drmemory/optionsx.h:610: OPTION_CLIENT_SCOPE(drmemscope, fuzz_arg_data, uint, 0,
0, 31,
Maybe "fuzz_data_index" or "fuzz_data_idx" or "fuzz_data_pos"?

https://codereview.appspot.com/276780043/diff/20001/drmemory/optionsx.h#newco...
drmemory/optionsx.h:613: OPTION_CLIENT_SCOPE(drmemscope, fuzz_arg_size, uint, 1,
0, 31,
Ditto

https://codereview.appspot.com/276780043/diff/20001/drmemory/optionsx.h#newco...
drmemory/optionsx.h:616: OPTION_CLIENT_SCOPE(drmemscope, fuzz_count, int, 100,
0, INT_MAX,
How about "fuzz_repeat" or "fuzz_iters": "count" to me is a little confusing b/c
it could refer to size of buf or sthg.