Commit Graph

5 Commits

Author SHA1 Message Date
Christian Holler
5e6434ac23 Bug 1431090 - Add FuzzingInterface support to JS engine. r=jandem
This patch adds basic support for the fuzzing interface in the JS engine on top
of the last patch. This includes all the necessary code except for actual
targets (just an example target skeleton) and also makes sure that the fuzzing
code is packaged for the standalone release.

MozReview-Commit-ID: D6Tyebz3jZS

--HG--
extra : rebase_source : f07a5d2bf8e09fb6c93501e58fbb958004e2fa05
2018-01-17 17:05:04 +01:00
Coroiu Cristina
faa2f8c7da Backed out 2 changesets (bug 1431090) for Bf bustage at src/tools/fuzzing/interface/harness/FuzzerTestHarness.h
Backed out changeset 2e98bda3f397 (bug 1431090)
Backed out changeset eb6acc9e44ad (bug 1431090)

--HG--
rename : tools/fuzzing/registry/FuzzerRegistry.cpp => tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.cpp
rename : tools/fuzzing/registry/FuzzerRegistry.h => tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.h
rename : tools/fuzzing/interface/harness/FuzzerRunner.cpp => tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.cpp
rename : tools/fuzzing/interface/harness/FuzzerRunner.h => tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.h
rename : tools/fuzzing/interface/harness/FuzzerTestHarness.h => tools/fuzzing/libfuzzer/harness/LibFuzzerTestHarness.h
rename : tools/fuzzing/interface/harness/moz.build => tools/fuzzing/libfuzzer/harness/moz.build
2018-01-23 13:49:26 +02:00
Christian Holler
08e812cc03 Bug 1431090 - Add FuzzingInterface support to JS engine. r=froydnj
This patch adds basic support for the fuzzing interface in the JS engine on top
of the last patch. This includes all the necessary code except for actual
targets (just an example target skeleton) and also makes sure that the fuzzing
code is packaged for the standalone release.

MozReview-Commit-ID: D6Tyebz3jZS

--HG--
extra : rebase_source : 58e4d85e657347b061de0ed912365f2a955a86e3
2018-01-17 17:05:04 +01:00
Mike Hommey
38ff4b7d87 Bug 1426558 - Make autospider builds not rely on system libnspr. r=sfink
The only reason autospider builds succeed in running tests at the moment
is that there is a libnspr4 library installed at the system level on
Centos that is binary compatible with what the js shell requires.

While on the long run we should just avoid depending on libnspr4 at all,
in the short term, we should make the effort to make those tests use the
libnspr4 present in dist/bin.

For the tests executed from js/src/Makefile.in, it turns out there is
already a level of wrapping that does that, relying on run-mozilla.sh,
which is only installed on gecko builds. Installing it on standalone js
builds solve half the problem.

The other half is addressed by setting LD_LIBRARY_PATH before invoking
the js shell in the various places it's invoked.

--HG--
extra : rebase_source : 25f4b1f5c78eb84e48046dc83798f07eb02d4a81
2017-12-21 10:11:13 +09:00
Mike Hommey
3d67bc07a1 Bug 1417309 - Move some definitions from top-level moz.build to application-specific moz.build files. r=nalexander
When building with a --enable-project that is neither js nor a
toolkit-based one (like browser or mobile/android), we don't want to be
building things that are specific to gecko and/or spidermonkey.

At the same time, this lifts the exception that js standalone doesn't
have an app.mozbuild included, and makes the moz.build parsers that
don't set a MOZ_BUILD_APP get the same information as they were through
toolkit.mozbuild.

We still keep mfbt, build and a few other DIRS set from the top-level,
because at the moment, there aren't really any --enable-project that
would benefit from those not being recursed.
2017-11-16 08:37:32 +09:00