Unroll improvements

[mmisono]

Add support of using positional params in unroll and increase the unroll limit to 100.

Example:

% sudo ./src/bpftrace -e 'BEGIN { unroll($1) { printf("hi\n"); } }' 5
Attaching 1 probe...
hi
hi
hi
hi
hi
^C

[danobi]

Do you think it would work to rewrite unroll() as a while loop (based on #1066)? I think it would result in less byte code. I can't think of any reasons why it would break existing programs.

[danobi]

Hmm except on systems without loop support.

[fbs]

Other than this lgtm

[mmisono]

Fixed parser.yy. Thanks @fbs
probe.interval_order tests failed for some reason, but I believe it wasn't related to this PR.

---

Do you think it would work to rewrite unroll() as a while loop (based on #1066)?

I think it would, but potentially unrolling optimize an execution speed so I guess keeping unrolling as is is good.

[fbs]

probe.interval_order tests failed for some reason, but I believe it wasn't related to this PR.

It always was a bit flaky but the new CI seems to have made it worse, got a commit to remove it in #1066

[fbs]

Bit curious where the 100 came from (or 20 for that matter). What is your usecase here? :)

[mmisono]

Actually there is no particular reason for 100, I just want to benchmark bpftrace (and BPF program) performance and unrolling is an easy way to generate long instructions. I feel 20 is a bit small. Maybe introducing BPFTRACE_MAX_UNROLL env variables is better. I think the limiting is useful because it helps us to prevent unrolling a large number of loop which consequently causes a stack overflow or something (this is especially useful when fuzzing since fuzzer generates unexpected inputs)

By the way, it is easy to circumvent unroll limitation: unroll(10) { unroll(10) { $i++; } }.

[fbs]

Reminder to add a changelog entry for this (#1255) before merging

[mmisono]

Rebased onto master and updated a changelog.