On Wed, Apr 19, 2017 at 10:44 AM, William Tu <[email protected]> wrote:
> Thanks for the reply.
>
>> could you increase the max to 1M or so
>> and see what the actual number of insns it needs?
>
> it takes 112,762 insns. And the kernel runs a while (~6 seconds) to verify it.
>
>> If the program is short, as you say, can you debug
>> the state prunning to see why it's not recognized?
>
> Compared with the non-volatile bytecode, I found most of the pruning
> does not apply. (the is_state_visited() does not find equivalent
> state)
>
>> I'm guessing stack slots are too different. If so,
>> can you apply the same hueristics we have for registers
>> to stack slots ?
>> In other words apply upper half of states_equal()
>> to lower half?
>>
> OK, I'm still trying to find out the root cause. Will update later.
>
I first tried collecting some verifier stats, by patching verifier.c
and count the reason of state_equal fails, either due to register
difference (upper half) or stack difference (lower half of
states_equal). For the volatile program, the pruning fails all due to
register difference, not stack slot.
Result with volatile:
processed 112762 insns
prune success 538 failed due to reg 6231 stack 0
while the same program without using volatile (but use > 512 stack):
processed 2331 insns
prune success 78 failed due to reg 112 stack 4
Once use volatile, I guess there are too many register spill or load
from stack, changing the register type from CONST_IMM to UNKNOWN, so I
applies the
if (rold->type == CONST_IMM && rcur->type == UNKNOWN_VALUE) {
continue;
}
to upper half of state_equal, but makes no difference. I couldn't
think of any other hueristics at this moment. Thanks.
Regards,
William
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
