[Webkit-unassigned] [Bug 203898] Add FuzzerAgent that reads predictions from a file

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=203898

--- Comment #19 from Mark Lam <mark.lam at apple.com> ---
Comment on attachment 383865
  --> https://bugs.webkit.org/attachment.cgi?id=383865
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=383865&action=review

>>>> Source/JavaScriptCore/runtime/FuzzerPredictions.cpp:81
>>>> +        // If end offset > 127, then the end offset is 0.
>>> 
>>> Why are start and end 7-bit ints?  They came from the character position in the source string.  Given a long enough source string, they can be greater than 7-bits.  Am I missing something?
>> 
>> They are defined as 7-bit unsigned integers in ExpressionRangeInfo.h. The behavior described is implemented in UnlinkedCodeBlock::addExpressionInfo(). (There's 25 bits worth of instructionOffset and divotPoint each.)
> 
> Ah, thanks.  I worked with this code many years ago, but I've since forgotten about it.  The comments in UnlinkedCodeBlock::addExpressionInfo() explains why 7 bits is fine:
> 
>     ...
>     } else if (startOffset > ExpressionRangeInfo::MaxOffset) {
>         // If the start offset is out of bounds we clear both offsets
>         // so we only get the divot marker. Error message will have to be reduced
>         // to line and charPosition number.
>         startOffset = 0;
>         endOffset = 0;
>     } else if (endOffset > ExpressionRangeInfo::MaxOffset) {
>         // The end offset is only used for additional context, and is much more likely
>         // to overflow (eg. function call arguments) so we are willing to drop it without
>         // dropping the rest of the range.
>         endOffset = 0;
>     }
> 
> 1. startOffset and endOffset is always relative to the divot of an expression string, not absolute positions.  Hence, it is likely that they will fit within 7 bits.
> 2. startOffset and endOffset are only used for helping to get more intelligent error strings.  Hence, it is not critical for them to be accurate.  They are a best effort attempt, and we're willing to drop them (set to 0) if we can't record the actual offsets.
> 
> What this means is that you shouldn't be using the start and end offsets in your lookup key.  Instead, just use the line and column values that are fetched by expressionRangeForBytecodeIndex().  But maybe I'm not getting your intent.  Why are you using the start and end positions anyway?

Tuomas explained to me offline that this is not an issue.  For the purpose of the predictions generator, this works adequately.  We don't need something more accurate.  Carry on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191120/668cfe9b/attachment.htm>