Hi folks,

Ever wanted to run tests with Debug ASSERTs enabled but the speed of the Debug 
build is so slow that it is a drag on your productivity?  Well, now you can get 
a faster testing build in one of two ways:

1. Build WebKit with "make testing” (or “make t”)
2. Build WebKit with “make release+assert” (or “make ra”)

The “testing” make target builds a Debug build with the clang optimization 
level forced to -O3.  

    The forcing of -O3 is achieved using 
"Tools/Scripts/set-webkit-configuration --force-optimization-level=O3”.  See 
trac.webkit.org/r254080 <http://trac.webkit.org/r254080>.
    With this configuration, you can run JSC tests or layout tests like normal, 
except it will run faster.

    How much faster?
        Using a normal debug build, the JSC tests takes about 6 hours to 
        Using the “testing” build, the JSC tests takes less than 30 minutes to 

The “release+assert” make target builds a Release build with ASSERT_ENABLED=1 

    With this configuration, you can run JSC tests.
    Currently, if you run this on the layout tests, you will see a lot of 
ASSERT failures, which brings us to ...

Since trac.webkit.org/r254087 <http://trac.webkit.org/r254087>, the 
ASSERT_DISABLED flag has been completely replaced with ASSERT_ENABLED.  

For code that guards fields and code needed to support debug ASSERTs, please 
use #if ASSERT_ENABLED going forward.

Please do NOT use #ifndef NDEBUG.

The reason the layout tests are failing ASSERTs when run on the 
“release+assert” build is because there are assertion support code above 
JavaScriptCore that are still guarded with #ifndef NDEBUG.  If you would like 
to help fix some of these, do the following:

1. Build WebKit with “make release+assert”.
2. Run "Tools/Scripts/run-webkit-tests —release”.
3. Look for tests that crashed with “ASSERTION FAILED: “ in the crash log e.g. 
"ASSERTION FAILED: m_tokenizer.isInDataState()”.
4. Find anything that the assertion depends on which is guarded by #ifndef 
NDEBUG, and replace it with  #if ASSERT_ENABLED.
5. Re-build WebKit and retest.

In general, there is probably no reason to ever use #ifndef NDEBUG.  Apart from 
assertion code, logging (and possibly other) code may also be affected by this 
same issue.

Miscellaneous details
The “testing” and “release+assert” make targets are available to use starting 
in trac.webkit.org/r254227 <http://trac.webkit.org/r254227>.  I only tested 
these make targets on Mac.  For other ports, some work may be required to get 
the builds configured similarly.

One caution about using the “testing” target: it configures the build 
environment using set-webkit-configuration.  That means unless you clear the 
configuration using "set-webkit-configuration --force-optimization-level=none”, 
it will force the clang optimization level to -O3 for all builds that follow, 
debug or release.  This is similar to how "set-webkit-configuration --asan” 
works.  Alternatively, you can also do "set-webkit-configuration —reset” to 
clear all configurations set using set-webkit-configuration.

If typing “--force-optimization-level” is too long and painful, “--force-opt” 
also works.



webkit-dev mailing list

Reply via email to