Add fuzzing support for inline runtime functions

Add fuzzing support for inline runtime functions

The inline runtime functions are now included in the fuzzing of the natives. The chack for the expected number of arguments passed have been moved to the parser which will generate a syntax error if a runtime function (either C++ or inline) is called with a different number of arguments than expected.

Committed: http://code.google.com/p/v8/source/detail?r=4096

[Erik Corry, 2010-02-08 19:27:13]

I think this is a very good idea and definitely worth doing for the other
architectures too.  Perhaps we should just abort the VM if the arg count
mismatches?  As long as we get a reasonable stack trace that seems safer than
continuing after an attacker has attempted to subvert the %_ natives.

http://codereview.chromium.org/573056/diff/1/2
File src/ia32/codegen-ia32.cc (right):

http://codereview.chromium.org/573056/diff/1/2#newcode4969
src/ia32/codegen-ia32.cc:4969: frame_->Push(Factory::undefined_value());
This and the similar cases below should have a comment to the effect that we
never expect this to happen.  Alternatively we could define some macro called
RETURN_UNDEFINED_ON_ARGC_MISMATCH and use it throughout.  Then we could put the
comment on the macro definition.

[Mads Ager (chromium), 2010-02-09 07:50:21]

On 2010/02/08 19:27:13, Erik Corry wrote:
> I think this is a very good idea and definitely worth doing for the other
> architectures too.  Perhaps we should just abort the VM if the arg count
> mismatches?  As long as we get a reasonable stack trace that seems safer than
> continuing after an attacker has attempted to subvert the %_ natives.

As discussed offline, I would throw a compile-time exception in case of arg
count mismatch.  That matches the way we handle inconsistencies in the other
runtime functions.

[Søren Thygesen Gjesse, 2010-03-10 15:45:26]

On 2010/02/09 07:50:21, Mads Ager wrote:
> On 2010/02/08 19:27:13, Erik Corry wrote:
> > I think this is a very good idea and definitely worth doing for the other
> > architectures too.  Perhaps we should just abort the VM if the arg count
> > mismatches?  As long as we get a reasonable stack trace that seems safer
than
> > continuing after an attacker has attempted to subvert the %_ natives.
> 
> As discussed offline, I would throw a compile-time exception in case of arg
> count mismatch.  That matches the way we handle inconsistencies in the other
> runtime functions.

This is now updated to throw a syntax error in case of passing an unexpected
number of arguments to a runtime function (for the runtime functions implemented
in C++ and the inline ones).

Ported to x64 and ARM as well.

Could you have another look?

[Mads Ager (chromium), 2010-03-11 07:36:13]

LGTM

http://codereview.chromium.org/573056/diff/13002/11006
File src/codegen.cc (right):

http://codereview.chromium.org/573056/diff/13002/11006#newcode400
src/codegen.cc:400: //if (entry->nargs != new_entry->nargs) return false;
Remove please.

http://codereview.chromium.org/573056/diff/13002/11007
File test/cctest/test-log-stack-tracer.cc (right):

http://codereview.chromium.org/573056/diff/13002/11007#newcode236
test/cctest/test-log-stack-tracer.cc:236: // _FastCharCodeAt is not used in our
tests.
Update comment?

[Søren Thygesen Gjesse, 2010-03-11 09:16:07]

http://codereview.chromium.org/573056/diff/13002/11006
File src/codegen.cc (right):

http://codereview.chromium.org/573056/diff/13002/11006#newcode400
src/codegen.cc:400: //if (entry->nargs != new_entry->nargs) return false;
On 2010/03/11 07:36:13, Mads Ager wrote:
> Remove please. 

Done.

http://codereview.chromium.org/573056/diff/13002/11007
File test/cctest/test-log-stack-tracer.cc (right):

http://codereview.chromium.org/573056/diff/13002/11007#newcode236
test/cctest/test-log-stack-tracer.cc:236: // _FastCharCodeAt is not used in our
tests.
On 2010/03/11 07:36:13, Mads Ager wrote:
> Update comment?

Done.