Building_v8_Windows.md

Building Chrome V8 on Windows

In order to be able to build v8 from scratch on Windows for x64, please follow the following steps.

These instructions were updated to work with Windows 11 Build 10.0.22621, but this should also work on WInodws 10

NOTE: While the Chrome team does provide decent documentation, there are some nuances and other additional steps that must be done for v8 to compile on Windows.

Documentation:

• https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#Setting-up-Windows
• https://v8.dev/docs/source-code
• https://v8.dev/docs/build
• https://medium.com/angular-in-depth/how-to-build-v8-on-windows-and-not-go-mad-6347c69aacd4

Some Nuances:

• As of April/May 2023, Chromium requires Visual Studio 2022 (>=17.0.0) to build
• For debugging (that will be us) Visual Studio 2022 is needed. Anything below might result in a build failure
• Desktop development with C++ components and the MFC/ATL support modules must be installed in Visual Studio.
• Building v8 in Debug mode with ASan on Windows is not supported, as it's not yet implemented in LLVM.
  • If you need this functionality, build v8 on Linux or macOS.

Get a Fresh Dev VM (Optional):

If you want to start on a fresh Windows 11 Development VM with Visual Studio 2022 then download one of the last W11 Dev VM's from Microsoft:

• VirtualBox
• VMWare

If you want to start on a fresh Windows 10 Development VM with Visual Studio 2019 then download one of the last W10 Dev VM's from Microsoft:

• VirtualBox
• VMWare

Setting Up Windows:

Once you have Visual Studio 2022 installed, you will need to install the following additional components:

• Desktop Development with C++
• Python Development
• C++ ATL for Latest v143 Build Tools (x86 & x64)
• C++ MFC for Latest v143 Build Tools (x86 & x64)
• C++ Clang Compiler for Windows (15.0.1)
• C++ Clang tools for Windows (15.0.1 - x64/x86)
• C++ CMake tools for Windows
• Windows 11 SDK (10.0.22621.0)

Next, we need to install the "SDK Debugging Tools" to be able to build and debug v8.

Note: If you downloaded the W11 Development VM, this should already be installed. But if you install the SDK, make sure that you have the correct install path of C:\Program Files (x86)\Windows Kits\10\WindowsSDK and that you select Debugging Tools, or you will have build failures.

To do that, either download the Windows 11 SDK (10.0.22621.755) or do the following if you installed the SDK via Visual Studio:

1. Open up Control Panel
2. Click Program
3. Click "Programs and Features"
4. Select the "Windows Software Development Kit"
5. Click "Change"
6. In the new Window, select "Change"
7. Click "Change"
8. Check the "Debugging Tools For Windows" Option
9. Click "Change"
10. Let the Debugging Tools Install

Download Chrome Tools and V8

First, start by creating a folder where you will be storing Google's tools and v8. In my case I made a new directory called dev in my C:\ drive.

Download the depot_tools and extract it to your previously created folder. In my case it will be extracted to C:\dev\depot_tools.

Warning: DO NOT use drag-n-drop or copy-n-paste extract from Explorer, this will not extract the hidden “.git” folder which is necessary for depot_tools to auto update itself. You can use “Extract all…” from the context menu though.

Assuming that you unzipped the budle to C:\dev\depot_tools, we now need to add the following Environmental Variables:

• Modify the PATH System Variable and put C:\dev\depot_tools at the front.
• Add the DEPOT_TOOLS_WIN_TOOLCHAIN User Variable and set it to 0.
  • This tells depot_tools to use your locally installed version of Visual Studio
• Add the vs2022_install User Variable and set it to your installation path of Visual Studio.
  • For 2022 Community it would be set to => C:\Program Files (x86)\Microsoft Visual Studio\2022\Community

Once done, open up cmd.exe, cd to your depot_tools directory and then run the following command:

> gclient

On the first run, gclient will install all the Windows-specific bits needed to work with the code, including msysgit and python.

• If you run gclient from a non-cmd shell (e.g., cygwin, PowerShell), it may appear to run properly, but msysgit, python, and other tools may not get installed correctly.
• If you see strange errors with the file system on the first run of gclient, you may want to disable Windows Indexing.

After running gclient open a command prompt and type where python and confirm that the depot_tools python.bat comes ahead of any copies of python.exe, like so:

C:\dev\depot_tools>where python
C:\dev\depot_tools\python.bat
C:\Users\User\AppData\Local\Microsoft\WindowsApps\python.exe

Create a v8 directory within your C:\dev folder (assuming that's what you created) for the checkout and change to it:

> mkdir v8 && cd v8

Run the fetch tool from depot_tools to check out the v8 code and its dependencies:

> fetch v8

Once the command has completed (~15-30 minutes), we now need to change to the v8 directory and sync the dependencies by running the following command:

> cd v8
> git fetch
> gclient sync

NOTE: Usually, you can update your current v8 branch with git pull. Note that if you’re not on a branch, git pull won’t work, and you’ll need to use git fetch instead.

Building V8

Now that we have all our tools installed, and dependencies synced, it's time to build v8.

All of your commands should be executed using Windows Command Shell inside the v8 source directory. We will be executing python scripts as part of the build process and we need to ensure that the python executable from build_tools is used.

WARNING: Take note, that there is a problem in the way Windows can associate python files with other versions of python installed on your PC. v8 relies on certain older Python v2 scripts, so always execute commands in the python path/to/script params syntax!

So, once we're in the v8 folder, we can execute the following command to build the debug version of v8:

> python3 tools\dev\gm.py x64.debug

If you want the release version, just change x64.debug to x64.release in the command.

Let this command run, and go get a coffee ☕ as this will take ~2-3 hours to build.

If the compile is successful your console output should be pretty similar to mines, as shown below:

C:\dev\v8\v8>python tools/dev/gm.py x64.debug
# mkdir -p out\x64.debug
# echo > out\x64.debug\args.gn << EOF
is_component_build = true
is_debug = true
symbol_level = 2
target_cpu = "x64"
v8_enable_sandbox = true
use_goma = false
v8_enable_backtrace = true
v8_enable_fast_mksnapshot = true
v8_enable_slow_dchecks = true
v8_optimized_debug = false
EOF
# gn gen out\x64.debug
Done. Made 190 targets from 103 files in 5968ms
# autoninja -C out\x64.debug d8
"C:\dev\depot_tools\bootstrap-2@3_8_10_chromium_26_bin\python3\bin\python3.exe" C:\dev\depot_tools\ninja.py -C out\x64.debug d8 -j 6
ninja: Entering directory `out\x64.debug'
[2137/2137] LINK d8.exe d8.exe.pdb
Done! - V8 compilation finished successfully.

Testing d8

Alright! So, we just successfully compiled v8, nice! If you haven't already noticed, gm also built d8 for us, which is v8's developer shell.

d8 is useful for running some JavaScript locally or debugging changes you have made to V8. This will be useful for us in better understanding v8 and writing exploits.

To test if d8 was successfully built, let's execute it with the --print-bytecode command, like so:

> out\x64.debug\d8 --print-bytecode
V8 version 11.6.0 (candidate)
d8>

From here, to make sure that we can see the bytecode, let's execute a simple function like Array.from(String('12345')) which simply creates an array with each number in the index of the string.

Your output should be similar to mines:

d8> Array.from(String('12345'))
[generated bytecode for function:  (0x02330025a8c9 <SharedFunctionInfo>)]
Bytecode length: 28
Parameter count 1
Register count 5
Frame size 40
Bytecode age: 0
         000002330025A94A @    0 : 21 00 00          LdaGlobal [0], [0]
         000002330025A94D @    3 : c3                Star2
         000002330025A94E @    4 : 2d f8 01 02       GetNamedProperty r2, [1], [2]
         000002330025A952 @    8 : c4                Star1
         000002330025A953 @    9 : 21 02 04          LdaGlobal [2], [4]
         000002330025A956 @   12 : c2                Star3
         000002330025A957 @   13 : 13 03             LdaConstant [3]
         000002330025A959 @   15 : c1                Star4
         000002330025A95A @   16 : 63 f7 f6 06       CallUndefinedReceiver1 r3, r4, [6]
         000002330025A95E @   20 : c2                Star3
         000002330025A95F @   21 : 5f f9 f8 f7 08    CallProperty1 r1, r2, r3, [8]
         000002330025A964 @   26 : c5                Star0
         000002330025A965 @   27 : aa                Return
Constant pool (size = 4)
000002330025A911: [FixedArray] in OldSpace
 - map: 0x023300002231 <Map(FIXED_ARRAY_TYPE)>
 - length: 4
           0: 0x0233000058e5 <String[5]: #Array>
           1: 0x0233000060a1 <String[4]: #from>
           2: 0x023300006dfd <String[6]: #String>
           3: 0x02330025a8a9 <String[5]: #12345>
Handler Table (size = 0)
Source Position Table (size = 0)
["1", "2", "3", "4", "5"]

Congratulations, you built v8 and d8!

Downloading Pre-Built Binaries

In case you don't want to compile V8, you can just grab fresh Chrome binaries built with ASan from here. Additionally, you can use OmahaProxy CSV Viewer to look for specific branch base positions by specifying a version of Chrome you want to target, and then just downloading the appropriate build from the chromium browser list.

do you know how to run v8 tests on windows since i succeed to build

i am working on a big subject. i need to crawl data from XHR request. but some of those XHR requests have a sign key as a request parameter to prevent auto-crawl data, although the sign key is calculated by javascripts which we can retrieve but mixed.
in order to solve this problem, i need to analyze the data flow which the whole XHR request object depends on and reconstruct the AST and regenerate the neat javascript source code, so i can run the javascript to build the XHR request to get data.
would you please give me some guidance

Hi, thanks for the documentation, with the steps provided i was able to build the v8 successfully. Now i want to link the v8 libraries into my C++ application and start calling the V8 methods in my code. In order to use the v8 in the c++ application, the v8 libraries has to be linked into the application, but i couldn't find any of V8 static or dynamic libraries (libv8_monolith.a, v8_monolith.lib, libv8_monolith.so, v8_monolith.dll, etc.) in the v8 folder after building it. can you please clarify?
Thanks
Nagaraj

i got error when running gclient sync

C:\tools\v8_temp\v8>gclient sync -D
Updating depot_tools...
Syncing projects: 100% (27/27), done.

________ running 'python v8/tools/clang/scripts/update.py' in 'C:\tools\v8_temp'
Traceback (most recent call last):
  File "v8/tools/clang/scripts/update.py", line 1051, in <module>
    sys.exit(main())
  File "v8/tools/clang/scripts/update.py", line 1035, in main
    sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
  File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\os.py", line 1021, in fdopen
    return io.open(fd, *args, **kwargs)
ValueError: can't have unbuffered text I/O
Error: Command 'python v8/tools/clang/scripts/update.py' returned non-zero exit status 1 in C:\tools\v8_temp
Traceback (most recent call last):
  File "v8/tools/clang/scripts/update.py", line 1051, in <module>
    sys.exit(main())
  File "v8/tools/clang/scripts/update.py", line 1035, in main
    sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
  File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\os.py", line 1021, in fdopen
    return io.open(fd, *args, **kwargs)
ValueError: can't have unbuffered text I/O

when I run chrome with command --js-flags=allow-native-syntax and then I use %DebugPrint to debug v8 in chrome, but I find that the information of jsobject doesn't display completely, it just show me a address, I want to know whether it is normal or I show add some flags when I compile chrome?

Has anyone encountered this issue when trying to build a project using v8?
v8.dll.lib, v8_libplatform.dll.lib, v8_libbase.dll.lib are all linked in the Project's properties.

error LNK2019: unresolved external symbol "class std::unique_ptr<class v8::Platform,struct std::default_delete<class v8::Platform> > __cdecl v8::platform::NewDefaultPlatform(int,enum v8::platform::IdleTaskSupport,enum v8::platform::InProcessStackDumping,class std::unique_ptr<class v8::TracingController,struct std::default_delete<class v8::TracingController> >,enum v8::platform::PriorityMode)" (?NewDefaultPlatform@platform@v8@@YA?AV?$unique_ptr@VPlatform@v8@@U?$default_delete@VPlatform@v8@@@std@@@std@@HW4IdleTaskSupport@12@W4InProcessStackDumping@12@V?$unique_ptr@VTracingController@v8@@U?$default_delete@VTracingController@v8@@@std@@@4@W4PriorityMode@12@@Z) referenced in function main

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "libplatform/libplatform.h"
#include "v8.h"

int main(int argc, char* argv[]) {
    // Initialize V8.
    v8::V8::InitializeICUDefaultLocation(argv[0]);
    v8::V8::InitializeExternalStartupData(argv[0]);
    std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
    v8::V8::InitializePlatform(platform.get());
    v8::V8::Initialize();
}

Been dealing with this one for awhile and would appreciate some insight if anyone knows how to resolve this.

I have the same problem when trying to link program in VS 2022. I guess the reason are that v8 use it's own implementation of the STL. The std::unique_ptr inside the main is not what the v8 use (Seems to use something like std::cr::unique_ptr). I think that the argument use_custom_libcxx = false should fix this, but I got some compilation problem when using this setting.

As soon as we set use_custom_cxx = false, it seems abseil then fails to link (all obj files build but final linking fails) regardless of whether use_lld = true/false. Are you aware of a workaround?

how to use visual stdio debug v8?

I have the same problem when trying to link program in VS 2022. I guess the reason are that v8 use it's own implementation of the STL. The std::unique_ptr inside the main is not what the v8 use (Seems to use something like std::cr::unique_ptr). I think that the argument use_custom_libcxx = false should fix this, but I got some compilation problem when using this setting.

I have the same issue, have anyone found any fix?

“C:\Code\workspace\v8\v8\out\default\all.sln”(默认目标) (1) ->
“C:\Code\workspace\v8\v8\out\default\obj\test\wasm-api-tests\wasm_api_tests.vcxproj”(默认目标) (68) ->
  lld-link : error : truncated or malformed archive (string table at long name offset 24318not terminated) [C:\Code\wor
kspace\v8\v8\out\default\obj\test\wasm-api-tests\wasm_api_tests.vcxproj]
  C:\Code\workspace\v8\v8\out\default\obj\test\wasm-api-tests\wasm_api_tests.vcxproj(122,5): error MSB3073: 命令“call nin
ja.exe -C C:\Code\workspace\v8\v8\out\default\  wasm_api_tests.exe”已退出，代码为 1。