nimbus-eth1/nimbus.nimble

112 lines
5.4 KiB
Plaintext
Raw Normal View History

mode = ScriptMode.Verbose
packageName = "nimbus"
version = "0.1.0"
author = "Status Research & Development GmbH"
description = "An Ethereum 2.0 Sharding Client for Resource-Restricted Devices"
license = "Apache License 2.0"
skipDirs = @["tests", "examples"]
# we can't have the result of a custom task in the "bin" var - https://github.com/nim-lang/nimble/issues/542
# bin = @["build/nimbus"]
2020-04-24 07:29:15 +00:00
requires "nim >= 1.2.0",
"bncurve",
"chronicles",
"chronos",
"eth",
"json_rpc",
"libbacktrace",
"nimcrypto",
"stew",
"stint",
2022-07-22 02:05:42 +00:00
"rocksdb",
"ethash",
"blscurve",
"evmc",
"web3"
2018-01-30 10:51:13 +00:00
binDir = "build"
2022-03-30 20:27:10 +00:00
when declared(namedBin):
namedBin = {
"nimbus/nimbus": "nimbus",
"fluffy/fluffy": "fluffy",
"lc_proxy/lc_proxy": "lc_proxy",
2022-03-30 20:27:10 +00:00
"fluffy/tools/portalcli": "portalcli",
}.toTable()
proc buildBinary(name: string, srcDir = "./", params = "", lang = "c") =
if not dirExists "build":
mkDir "build"
# allow something like "nim nimbus --verbosity:0 --hints:off nimbus.nims"
var extra_params = params
for i in 2..<paramCount():
extra_params &= " " & paramStr(i)
exec "nim " & lang & " --out:build/" & name & " " & extra_params & " " & srcDir & name & ".nim"
proc test(path: string, name: string, params = "", lang = "c") =
# Verify stack usage is kept low by setting 750k stack limit in tests.
const stackLimitKiB = 750
EVMC: Small stacks when using EVMC, closes #575 (segfaults) This patch reduces stack space used with EVM in ENABLE_EVMC=1 mode, from 13 MB worst case to 550 kB, a 24x reduction. This completes fixing the "stack problem" and closes #575 (`EVM: Different segmentation faults when running the test suite with EVMC`). It also closes #256 (`recursive EVM call trigger unrecoverable stack overflow`). After this patch, it is possible to re-enable the CI targets which had to be disabled due to #575. This change is also a required precursor for switching over to "nearly EVMC" as the clean and focused Nimbus-internal API between EVM and sync/database processes, and is also key to the use of Chronos `async` in those processes when calling the EVM. (The motivation is the internal interface has to be substantially changed _anyway_ for the parallel sync and database processes, and EVMC turns out to be well-designed and well-suited for this. It provides good separation between modules, and suits our needs better than our other current interface. Might as well use a good one designed by someone else. EVMC is 98% done in Nimbus thanks to great work done before by @jangko, and we can use Nimbus-specific extensions where we need flexibility, including for performance. Being aligned with the ecosystem is a useful bonus feature.) All tests below were run on Ubuntu 20.04 LTS server, x86-64. This matches one of the targets that has been disabled for a while in CI in EVMC mode due to stack overflow crashing the tests, so it's a good choice. Measurements before =================== Testing commit `e76e0144 2021-04-22 11:29:42 +0700 add submodules: graphql and toml-serialization`. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default to avoid crash. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 38416 depthHigh 3 ... Stack range 13074720 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json These tests use 13.07 MB of stack to run, and so crash with the default stack limit on Ubuntu Server 20.04 (8MB). Exactly 12768 bytes per EVM call stack frame. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 14384 depthHigh 2 ... Stack range 3495456 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 3709600 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 7831600 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json These tests use 7.83MB of stack to run. About 7648 bytes per EVM call stack frame. It _only just_ avoids crashing with the default Ubuntu Server stack limit of 8 MB. However, it still crashes on Windows x86-64, which is why the Windows CI EVMC target is currently disabled. On Linux where this passes, this is so borderline that it affects work and testing of the complex storage code, because that's called from the EVM. Also, this greatly exceeds the default thread stack size. Measurements after ================== $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 600 # Because we can! 600k stack. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 1936 depthHigh 3 ... Stack range 556272 depthHigh 1022 Stack range 556512 depthHigh 1023 Stack range 556816 depthHigh 1023 Stack range 557056 depthHigh 1024 Stack range 557360 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 600 # Because we can! 600k stack. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 1392 depthHigh 2 ... Stack range 248912 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 264144 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 557360 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stStaticCall/static_CallRecursiveBombPreCall.json For both tests, a satisfying *544 bytes* per EVM call stack frame, and EVM takes less than 600 kB total. With other overheads, both tests run in 600 kB stack total at maximum EVM depth. We must add some headroom on this for database activity called from the EVM, and different compile targets. But it means the EVM itself is no longer a stack burden. This is much smaller than the default thread stack size on Linux (2MB), with plenty of margin. (Just fyi, it isn't smaller than a _small_ thread stack on Linux from a long time ago (128kB), and some small embedded C targets.) This size is well suited to running EVMs in threads. Further reduction ================= This patch solves the stack problem. Windows and Linux 64-bit EVMC CI targets can be re-enabled, and there is no longer a problem with stack usage. We can reduce further to ~340 bytes per frame and 350 kB total, while still complying with EVMC. But as this involves changing how errors are handled to comply fully with EVMC, and removing `dispose` calls, it's not worth doing now while there are other EVMC changes in progress that will have the same effect. A Nimbus-specific extension will allow us to avoid recursion with EVMC anyway, bringing bytes per frame to zero. We need the extension anyway, to support Chronos `async` which parallel transaction processing is built around. Interop with non-Nimbus over EVMC won't let us avoid recursion, but then we can't control the stack frame size either. To prevent stack overflow in interop I anticipate using (this method in Aleth) [https://github.com/ethereum/aleth/blob/6e96ce34e3f131e2d42f3cb00741b54e05ab029d/libethereum/ExtVM.cpp#L61]. Smoke test other versions of GCC and Clang/LLVM =============================================== As all builds including Windows use GCC or Apple's Clang/LLVM, this is just to verify we're in the right ballpark on all targets. I've only checked `x86_64` though, not 32-bit, and not ARM. It's interesting to see GCC 10 uses less stack. This is because it optimises `struct` returns better, sometimes skipping an intermediate copy. Here it benefits the EVMC API, but I found GCC 10 also improves the larger stack usage of the rest of `nimbus-eth1` as well. Apple clang 12.0.0 (clang-1200.0.26.2) on MacOS 10.15: - 544 bytes per EVM call stack frame GCC 10.3.0 (Ubuntu 10.3.0-1ubuntu1) on Ubuntu 21.04: - 464 bytes per EVM call stack frame GCC 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04) on Ubuntu 20.04 LTS: - 464 bytes per EVM call stack frame GCC 11.0.1 20210417 (experimental; Ubuntu 11-20210417-1ubuntu1) on Ubuntu 21.04: - 8 bytes per EVM call stack frame GCC 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 8.4.0 (Ubuntu 8.4.0-3ubuntu2) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 7.5.0 (Ubuntu 7.5.0-6ubuntu2) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) on Ubuntu 19.10: - 528 bytes per EVM call stack frame Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-04-26 15:01:00 +00:00
when not defined(windows):
const (buildOption, runPrefix) = ("", "ulimit -s " & $stackLimitKiB & " && ")
EVMC: Small stacks when using EVMC, closes #575 (segfaults) This patch reduces stack space used with EVM in ENABLE_EVMC=1 mode, from 13 MB worst case to 550 kB, a 24x reduction. This completes fixing the "stack problem" and closes #575 (`EVM: Different segmentation faults when running the test suite with EVMC`). It also closes #256 (`recursive EVM call trigger unrecoverable stack overflow`). After this patch, it is possible to re-enable the CI targets which had to be disabled due to #575. This change is also a required precursor for switching over to "nearly EVMC" as the clean and focused Nimbus-internal API between EVM and sync/database processes, and is also key to the use of Chronos `async` in those processes when calling the EVM. (The motivation is the internal interface has to be substantially changed _anyway_ for the parallel sync and database processes, and EVMC turns out to be well-designed and well-suited for this. It provides good separation between modules, and suits our needs better than our other current interface. Might as well use a good one designed by someone else. EVMC is 98% done in Nimbus thanks to great work done before by @jangko, and we can use Nimbus-specific extensions where we need flexibility, including for performance. Being aligned with the ecosystem is a useful bonus feature.) All tests below were run on Ubuntu 20.04 LTS server, x86-64. This matches one of the targets that has been disabled for a while in CI in EVMC mode due to stack overflow crashing the tests, so it's a good choice. Measurements before =================== Testing commit `e76e0144 2021-04-22 11:29:42 +0700 add submodules: graphql and toml-serialization`. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default to avoid crash. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 38416 depthHigh 3 ... Stack range 13074720 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json These tests use 13.07 MB of stack to run, and so crash with the default stack limit on Ubuntu Server 20.04 (8MB). Exactly 12768 bytes per EVM call stack frame. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 14384 depthHigh 2 ... Stack range 3495456 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 3709600 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 7831600 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json These tests use 7.83MB of stack to run. About 7648 bytes per EVM call stack frame. It _only just_ avoids crashing with the default Ubuntu Server stack limit of 8 MB. However, it still crashes on Windows x86-64, which is why the Windows CI EVMC target is currently disabled. On Linux where this passes, this is so borderline that it affects work and testing of the complex storage code, because that's called from the EVM. Also, this greatly exceeds the default thread stack size. Measurements after ================== $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 600 # Because we can! 600k stack. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 1936 depthHigh 3 ... Stack range 556272 depthHigh 1022 Stack range 556512 depthHigh 1023 Stack range 556816 depthHigh 1023 Stack range 557056 depthHigh 1024 Stack range 557360 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 600 # Because we can! 600k stack. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 1392 depthHigh 2 ... Stack range 248912 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 264144 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 557360 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stStaticCall/static_CallRecursiveBombPreCall.json For both tests, a satisfying *544 bytes* per EVM call stack frame, and EVM takes less than 600 kB total. With other overheads, both tests run in 600 kB stack total at maximum EVM depth. We must add some headroom on this for database activity called from the EVM, and different compile targets. But it means the EVM itself is no longer a stack burden. This is much smaller than the default thread stack size on Linux (2MB), with plenty of margin. (Just fyi, it isn't smaller than a _small_ thread stack on Linux from a long time ago (128kB), and some small embedded C targets.) This size is well suited to running EVMs in threads. Further reduction ================= This patch solves the stack problem. Windows and Linux 64-bit EVMC CI targets can be re-enabled, and there is no longer a problem with stack usage. We can reduce further to ~340 bytes per frame and 350 kB total, while still complying with EVMC. But as this involves changing how errors are handled to comply fully with EVMC, and removing `dispose` calls, it's not worth doing now while there are other EVMC changes in progress that will have the same effect. A Nimbus-specific extension will allow us to avoid recursion with EVMC anyway, bringing bytes per frame to zero. We need the extension anyway, to support Chronos `async` which parallel transaction processing is built around. Interop with non-Nimbus over EVMC won't let us avoid recursion, but then we can't control the stack frame size either. To prevent stack overflow in interop I anticipate using (this method in Aleth) [https://github.com/ethereum/aleth/blob/6e96ce34e3f131e2d42f3cb00741b54e05ab029d/libethereum/ExtVM.cpp#L61]. Smoke test other versions of GCC and Clang/LLVM =============================================== As all builds including Windows use GCC or Apple's Clang/LLVM, this is just to verify we're in the right ballpark on all targets. I've only checked `x86_64` though, not 32-bit, and not ARM. It's interesting to see GCC 10 uses less stack. This is because it optimises `struct` returns better, sometimes skipping an intermediate copy. Here it benefits the EVMC API, but I found GCC 10 also improves the larger stack usage of the rest of `nimbus-eth1` as well. Apple clang 12.0.0 (clang-1200.0.26.2) on MacOS 10.15: - 544 bytes per EVM call stack frame GCC 10.3.0 (Ubuntu 10.3.0-1ubuntu1) on Ubuntu 21.04: - 464 bytes per EVM call stack frame GCC 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04) on Ubuntu 20.04 LTS: - 464 bytes per EVM call stack frame GCC 11.0.1 20210417 (experimental; Ubuntu 11-20210417-1ubuntu1) on Ubuntu 21.04: - 8 bytes per EVM call stack frame GCC 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 8.4.0 (Ubuntu 8.4.0-3ubuntu2) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 7.5.0 (Ubuntu 7.5.0-6ubuntu2) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) on Ubuntu 19.10: - 528 bytes per EVM call stack frame Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-04-26 15:01:00 +00:00
else:
# No `ulimit` in Windows. `ulimit -s` in Bash is accepted but has no effect.
EVMC: Small stacks when using EVMC, closes #575 (segfaults) This patch reduces stack space used with EVM in ENABLE_EVMC=1 mode, from 13 MB worst case to 550 kB, a 24x reduction. This completes fixing the "stack problem" and closes #575 (`EVM: Different segmentation faults when running the test suite with EVMC`). It also closes #256 (`recursive EVM call trigger unrecoverable stack overflow`). After this patch, it is possible to re-enable the CI targets which had to be disabled due to #575. This change is also a required precursor for switching over to "nearly EVMC" as the clean and focused Nimbus-internal API between EVM and sync/database processes, and is also key to the use of Chronos `async` in those processes when calling the EVM. (The motivation is the internal interface has to be substantially changed _anyway_ for the parallel sync and database processes, and EVMC turns out to be well-designed and well-suited for this. It provides good separation between modules, and suits our needs better than our other current interface. Might as well use a good one designed by someone else. EVMC is 98% done in Nimbus thanks to great work done before by @jangko, and we can use Nimbus-specific extensions where we need flexibility, including for performance. Being aligned with the ecosystem is a useful bonus feature.) All tests below were run on Ubuntu 20.04 LTS server, x86-64. This matches one of the targets that has been disabled for a while in CI in EVMC mode due to stack overflow crashing the tests, so it's a good choice. Measurements before =================== Testing commit `e76e0144 2021-04-22 11:29:42 +0700 add submodules: graphql and toml-serialization`. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default to avoid crash. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 38416 depthHigh 3 ... Stack range 13074720 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json These tests use 13.07 MB of stack to run, and so crash with the default stack limit on Ubuntu Server 20.04 (8MB). Exactly 12768 bytes per EVM call stack frame. $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 16384 # Requires larger stack than default. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 14384 depthHigh 2 ... Stack range 3495456 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 3709600 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 7831600 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json These tests use 7.83MB of stack to run. About 7648 bytes per EVM call stack frame. It _only just_ avoids crashing with the default Ubuntu Server stack limit of 8 MB. However, it still crashes on Windows x86-64, which is why the Windows CI EVMC target is currently disabled. On Linux where this passes, this is so borderline that it affects work and testing of the complex storage code, because that's called from the EVM. Also, this greatly exceeds the default thread stack size. Measurements after ================== $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 600 # Because we can! 600k stack. $ ./build/all_tests 9 | tee tlog [Suite] persist block json tests ... Stack range 1936 depthHigh 3 ... Stack range 556272 depthHigh 1022 Stack range 556512 depthHigh 1023 Stack range 556816 depthHigh 1023 Stack range 557056 depthHigh 1024 Stack range 557360 depthHigh 1024 [OK] tests/fixtures/PersistBlockTests/block1431916.json $ rm -f build/all_tests && make ENABLE_EVMC=1 test $ ulimit -S -s 600 # Because we can! 600k stack. $ ./build/all_tests 7 | tee tlog [Suite] new generalstate json tests ... Stack range 1392 depthHigh 2 ... Stack range 248912 depthHigh 457 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json ... Stack range 264144 depthHigh 485 [OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json ... Stack range 557360 depthHigh 1024 [OK] tests/fixtures/eth_tests/GeneralStateTests/stStaticCall/static_CallRecursiveBombPreCall.json For both tests, a satisfying *544 bytes* per EVM call stack frame, and EVM takes less than 600 kB total. With other overheads, both tests run in 600 kB stack total at maximum EVM depth. We must add some headroom on this for database activity called from the EVM, and different compile targets. But it means the EVM itself is no longer a stack burden. This is much smaller than the default thread stack size on Linux (2MB), with plenty of margin. (Just fyi, it isn't smaller than a _small_ thread stack on Linux from a long time ago (128kB), and some small embedded C targets.) This size is well suited to running EVMs in threads. Further reduction ================= This patch solves the stack problem. Windows and Linux 64-bit EVMC CI targets can be re-enabled, and there is no longer a problem with stack usage. We can reduce further to ~340 bytes per frame and 350 kB total, while still complying with EVMC. But as this involves changing how errors are handled to comply fully with EVMC, and removing `dispose` calls, it's not worth doing now while there are other EVMC changes in progress that will have the same effect. A Nimbus-specific extension will allow us to avoid recursion with EVMC anyway, bringing bytes per frame to zero. We need the extension anyway, to support Chronos `async` which parallel transaction processing is built around. Interop with non-Nimbus over EVMC won't let us avoid recursion, but then we can't control the stack frame size either. To prevent stack overflow in interop I anticipate using (this method in Aleth) [https://github.com/ethereum/aleth/blob/6e96ce34e3f131e2d42f3cb00741b54e05ab029d/libethereum/ExtVM.cpp#L61]. Smoke test other versions of GCC and Clang/LLVM =============================================== As all builds including Windows use GCC or Apple's Clang/LLVM, this is just to verify we're in the right ballpark on all targets. I've only checked `x86_64` though, not 32-bit, and not ARM. It's interesting to see GCC 10 uses less stack. This is because it optimises `struct` returns better, sometimes skipping an intermediate copy. Here it benefits the EVMC API, but I found GCC 10 also improves the larger stack usage of the rest of `nimbus-eth1` as well. Apple clang 12.0.0 (clang-1200.0.26.2) on MacOS 10.15: - 544 bytes per EVM call stack frame GCC 10.3.0 (Ubuntu 10.3.0-1ubuntu1) on Ubuntu 21.04: - 464 bytes per EVM call stack frame GCC 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04) on Ubuntu 20.04 LTS: - 464 bytes per EVM call stack frame GCC 11.0.1 20210417 (experimental; Ubuntu 11-20210417-1ubuntu1) on Ubuntu 21.04: - 8 bytes per EVM call stack frame GCC 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 8.4.0 (Ubuntu 8.4.0-3ubuntu2) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 7.5.0 (Ubuntu 7.5.0-6ubuntu2) on Ubuntu 20.04 LTS: - 544 bytes per EVM call stack frame GCC 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) on Ubuntu 19.10: - 528 bytes per EVM call stack frame Signed-off-by: Jamie Lokier <jamie@shareable.org>
2021-04-26 15:01:00 +00:00
# See https://public-inbox.org/git/alpine.DEB.2.21.1.1709131448390.4132@virtualbox/
# Also, the command passed to NimScript `exec` on Windows is not a shell script.
# Instead, we can set stack size at link time.
const (buildOption, runPrefix) =
(" -d:windowsNoSetStack --passL:-Wl,--stack," & $(stackLimitKiB * 2048), "")
buildBinary name, (path & "/"), params & buildOption
exec runPrefix & "build/" & name
task test, "Run tests":
test "tests", "all_tests", "-d:chronicles_log_level=ERROR -d:unittest2DisableParamFiltering"
task test_rocksdb, "Run rocksdb tests":
test "tests/db", "test_kvstore_rocksdb", "-d:chronicles_log_level=ERROR -d:unittest2DisableParamFiltering"
Added basic async capabilities for vm2. (#1260) * Added basic async capabilities for vm2. This is a whole new Git branch, not the same one as last time (https://github.com/status-im/nimbus-eth1/pull/1250) - there wasn't much worth salvaging. Main differences: I didn't do the "each opcode has to specify an async handler" junk that I put in last time. Instead, in oph_memory.nim you can see sloadOp calling asyncChainTo and passing in an async operation. That async operation is then run by the execCallOrCreate (or asyncExecCallOrCreate) code in interpreter_dispatch.nim. In the test code, the (previously existing) macro called "assembler" now allows you to add a section called "initialStorage", specifying fake data to be used by the EVM computation run by that test. (In the long run we'll obviously want to write tests that for-real use the JSON-RPC API to asynchronously fetch data; for now, this was just an expedient way to write a basic unit test that exercises the async-EVM code pathway.) There's also a new macro called "concurrentAssemblers" that allows you to write a test that runs multiple assemblers concurrently (and then waits for them all to finish). There's one example test using this, in test_op_memory_lazy.nim, though you can't actually see it doing so unless you uncomment some echo statements in async_operations.nim (in which case you can see the two concurrently running EVM computations each printing out what they're doing, and you'll see that they interleave). A question: is it possible to make EVMC work asynchronously? (For now, this code compiles and "make test" passes even if ENABLE_EVMC is turned on, but it doesn't actually work asynchronously, it just falls back on doing the usual synchronous EVMC thing. See FIXME-asyncAndEvmc.) * Moved the AsyncOperationFactory to the BaseVMState object. * Made the AsyncOperationFactory into a table of fn pointers. Also ditched the plain-data Vm2AsyncOperation type; it wasn't really serving much purpose. Instead, the pendingAsyncOperation field directly contains the Future. * Removed the hasStorage idea. It's not the right solution to the "how do we know whether we still need to fetch the storage value or not?" problem. I haven't implemented the right solution yet, but at least we're better off not putting in a wrong one. * Added/modified/removed some comments. (Based on feedback on the PR.) * Removed the waitFor from execCallOrCreate. There was some back-and-forth in the PR regarding whether nested waitFor calls are acceptable: https://github.com/status-im/nimbus-eth1/pull/1260#discussion_r998587449 The eventual decision was to just change the waitFor to a doAssert (since we probably won't want this extra functionality when running synchronously anyway) to make sure that the Future is already finished.
2022-11-01 15:35:46 +00:00
task test_evm, "Run EVM tests":
test "tests", "evm_tests", "-d:chronicles_log_level=ERROR -d:unittest2DisableParamFiltering"
## Fluffy tasks
2021-06-28 15:53:13 +00:00
task fluffy, "Build fluffy":
buildBinary "fluffy", "fluffy/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false"
task lc_bridge, "Build light client bridge":
buildBinary "beacon_light_client_bridge", "fluffy/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false -d:libp2p_pki_schemes=secp256k1"
task fluffy_test, "Run fluffy tests":
# Need the nimbus_db_backend in state network tests as we need a Hexary to
# start from, even though it only uses the MemoryDb.
test "fluffy/tests/portal_spec_tests/mainnet", "all_fluffy_portal_spec_tests", "-d:chronicles_log_level=ERROR -d:chronosStrictException -d:nimbus_db_backend=sqlite -d:PREFER_BLST_SHA256=false"
# Running tests with a low `mergeBlockNumber` to make the tests faster.
# Using the real mainnet merge block number is not realistic for these tests.
test "fluffy/tests", "all_fluffy_tests", "-d:chronicles_log_level=ERROR -d:chronosStrictException -d:nimbus_db_backend=sqlite -d:PREFER_BLST_SHA256=false -d:mergeBlockNumber:38130"
test "fluffy/tests/beacon_light_client_tests", "all_beacon_light_client_tests", "-d:chronicles_log_level=ERROR -d:chronosStrictException -d:nimbus_db_backend=sqlite -d:PREFER_BLST_SHA256=false"
task fluffy_tools, "Build fluffy tools":
buildBinary "beacon_chain_bridge", "fluffy/tools/bridge/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false -d:libp2p_pki_schemes=secp256k1"
buildBinary "eth_data_exporter", "fluffy/tools/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false"
buildBinary "content_verifier", "fluffy/tools/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false"
buildBinary "blockwalk", "fluffy/tools/", "-d:chronicles_log_level=TRACE -d:chronosStrictException"
buildBinary "portalcli", "fluffy/tools/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false"
task utp_test_app, "Build uTP test app":
buildBinary "utp_test_app", "fluffy/tools/utp_testing/", "-d:chronicles_log_level=TRACE -d:chronosStrictException"
task utp_test, "Run uTP integration tests":
test "fluffy/tools/utp_testing", "utp_test", "-d:chronicles_log_level=ERROR -d:chronosStrictException"
task fluffy_test_portal_testnet, "Build test_portal_testnet":
buildBinary "test_portal_testnet", "fluffy/scripts/", "-d:chronicles_log_level=DEBUG -d:chronosStrictException -d:unittest2DisableParamFiltering -d:PREFER_BLST_SHA256=false"
## Nimbus Verified Proxy tasks
task nimbus_verified_proxy, "Build Nimbus verified proxy":
buildBinary "nimbus_verified_proxy", "nimbus_verified_proxy/", "-d:chronicles_log_level=TRACE -d:chronosStrictException -d:PREFER_BLST_SHA256=false -d:libp2p_pki_schemes=secp256k1"
task nimbus_verified_proxy_test, "Run Nimbus verified proxy tests":
test "nimbus_verified_proxy/tests", "test_proof_validation", "-d:chronicles_log_level=ERROR -d:chronosStrictException -d:nimbus_db_backend=sqlite -d:PREFER_BLST_SHA256=false"