[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webkit-dev
Subject:    [webkit-dev] PSA: on make targets "testing" and "release+assert", ASSERT_ENABLED, and NDEBUG
From:       Mark Lam <mark.lam () apple ! com>
Date:       2020-01-08 23:11:31
Message-ID: 5F4FFF9C-F59C-4274-B28B-FCBD692F93C7 () apple ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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")

testing
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 complete.
        Using the "testing" build, the JSC tests takes less than 30 minutes to \
complete.

release+assert
The "release+assert" make target builds a Release build with ASSERT_ENABLED=1 \
defined.

    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 ...

#if ASSERT_ENABLED vs #ifndef NDEBUG
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.

Thanks.

Mark


[Attachment #5 (unknown)]

<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class="">Hi folks,<div class=""><br \
class=""></div><div class="">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? \
&nbsp;Well, now you can get a faster testing build in one of two ways:</div><div \
class=""><br class=""></div><div class="">1. Build WebKit with "make testing" (or \
"make t")</div><div class="">2. Build WebKit with "make release+assert" (or "make \
ra")</div><div class=""><br class=""></div><div class=""><b \
class="">testing</b></div><div class="">The "testing" make target builds a Debug \
build with the clang optimization level forced to -O3. &nbsp;</div><div class=""><br \
class=""></div><div class="">&nbsp; &nbsp; The forcing of -O3 is achieved using \
"Tools/Scripts/set-webkit-configuration --force-optimization-level=O3". &nbsp;See <a \
href="http://trac.webkit.org/r254080" class="">trac.webkit.org/r254080</a>.</div><div \
class="">&nbsp; &nbsp; With this configuration, you can run JSC tests or layout tests \
like normal, except it will run faster.</div><div class=""><br class=""></div><div \
class="">&nbsp; &nbsp; How much faster?</div><div class="">&nbsp; &nbsp; &nbsp; \
&nbsp; Using a normal debug build, the JSC tests takes about 6 hours to \
complete.</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; Using the "testing" build, \
the JSC tests takes less than 30 minutes to complete.</div><div class=""><br \
class=""></div><div class=""><b class="">release+assert</b></div><div class="">The \
"release+assert" make target builds a Release build with ASSERT_ENABLED=1 \
defined.</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; With this \
configuration, you can run JSC tests.</div><div class="">&nbsp; &nbsp; Currently, if \
you run this on the layout tests, you will see a lot of ASSERT failures, which brings \
us to ...</div><div class=""><br class=""></div><div class=""><b class="">#if \
ASSERT_ENABLED vs #ifndef NDEBUG</b></div><div class="">Since&nbsp;<a \
href="http://trac.webkit.org/r254087" class="">trac.webkit.org/r254087</a>, the \
ASSERT_DISABLED flag has been completely replaced with ASSERT_ENABLED. \
&nbsp;</div><div class=""><br class=""></div><div class="">For code that guards \
fields and code needed to support debug ASSERTs, please use #if ASSERT_ENABLED going \
forward.</div><div class=""><br class=""></div><div class="">Please do NOT use \
#ifndef NDEBUG.</div><div class=""><br class=""></div><div class="">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. &nbsp;If you would like to help fix some of these, do the \
following:</div><div class=""><br class=""></div><div class="">1. Build WebKit with \
"make release+assert".</div><div class="">2. Run "Tools/Scripts/run-webkit-tests \
—release".</div><div class="">3. Look for tests that crashed with "ASSERTION \
FAILED: " in the crash log e.g. "<span style="white-space: pre-wrap;" \
class="">ASSERTION FAILED: m_tokenizer.isInDataState()</span>".</div><div class="">4. \
Find anything that the assertion depends on which is guarded by #ifndef NDEBUG, and \
replace it with &nbsp;#if ASSERT_ENABLED.</div><div class="">5. Re-build WebKit and \
retest.</div><div class=""><br class=""></div><div class="">In general, there is \
probably no reason to ever use #ifndef NDEBUG. &nbsp;Apart from assertion code, \
logging (and possibly other) code may also be affected by this same issue.</div><div \
class=""><br class=""></div><div class=""><b class="">Miscellaneous \
details</b></div><div class="">The "testing" and "release+assert" make targets are \
available to use starting in <a href="http://trac.webkit.org/r254227" \
class="">trac.webkit.org/r254227</a>. &nbsp;I only tested these make targets on Mac. \
&nbsp;For other ports, some work may be required to get the builds configured \
similarly.</div><div class=""><br class=""></div><div class="">One caution about \
using the "testing" target: it configures the build environment using \
set-webkit-configuration. &nbsp;That means unless you clear the configuration using \
"set-webkit-configuration&nbsp;--force-optimization-level=none", it will force the \
clang optimization level to -O3 for all builds that follow, debug or release. \
&nbsp;This is similar to how "set-webkit-configuration --asan" works. \
&nbsp;Alternatively, you can also do "set-webkit-configuration —reset" to clear all \
configurations set using set-webkit-configuration.</div><div class=""><br \
class=""></div><div class="">If typing "--force-optimization-level" is too long and \
painful, "--force-opt" also works.</div><div class=""><br class=""></div><div \
class=""><div class="">Thanks.</div><div class=""><br class=""></div></div><div \
class="">Mark</div><div class=""><br class=""></div></body></html>



_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic