How does v8 load and execute the native machine code it generates?
Basically V8 creates a byte array containing the native instructions. It then copies the data into an executable memory region from which point on you can directly jump/call to it.
See FinalizeCode within the compiler which sets up a new Code object.
As for calling, you'll find the detailed frame description in frame-constants.h where you want
Related
As far as I know, the compiler compiles the code by converting it to a language that a computer can understand which is the machine language and this is done before running the code.
So, does the compiler compile my code each time I write a character in the file?
And if so, does it check the whole code? Or just the line that updated.
An important part to this question is the type of programming language(PL) we are talking about. Generally speaking, I would categorize PL into 3 groups:
Traditional PLs. Ex: C, C++, Rust
The compiler compiles the code into machine language when you hit the "build" button or the "run" button.
It doesn't compile every time you change the code, but a code linter does continuously observe your code and check it for errors.
Another note, when you change part of the code and compile it, the compiler doesn't recompile everything. It usually only recompile the current assembly file (or module or whatever you call them).
It is also important to note that a lot of modern IDEs, compile when you save the files.
There is also the hot reload feature. It is a smart compiler feature that can swap certain parts of the code while it is running.
Interpreted PLs Ex: python, JS and PHP
Those languages never get compiled; Rather, they get interpreted or translated into native code on the fly and in-memory when you run them.
Those languages usually employee a cache to accelerate the subsequent code execution.
Intermediary Code PL. Ex: Kotlin, java, C#
Have 2 stages of compilation:
Build time compilation.
Just in time (run-time) compilation.
Build time compilation converts the code into intermediary language (IL) machine code, which is special to the run-time.
This code only understood by the run time like Java runtime or dot net runtime
The second compilation happens when the programs get installed or ran for the first time. This is called just in time compilation (JIT)
The run-time convert the code into native code specific to the run-time OS.
While not specifically related to Frida's use of V8, I was reading this Frida release page and noticed it made the following reference:
Short of writing the whole agent in C, one could go ahead and build a
native library, and load it using Module.load(). This works but means
it has to be compiled for every single architecture, deployed to the
target, etc.
The comment by Ole alludes to this being possible, though I can't find any references other than the NodeJS C++ Addons features that are, of course, specific to NodeJS (though NodeJS does use V8).
tl;dr
How does one load a generic object such that all of its exported functions are callable from Javascript? Is this possible?
I was misinterpreting the context of the comment in the original link, it seems. I was under the impression that Module.load was a v8-ism, while it in fact appears to be a Frida-API.
https://frida.re/docs/javascript-api/#module
I figured this out about the time I was writing code to use Module.getExportByName to just pass the addresses of dlopen and dlsym to the entry of my CModule code.
https://webassembly.studio/ allows inspection of WebAssembly (WASM) files and the corresponding SpiderMonkey-generated x86 code. I'd like to similarly inspect instructions generated by V8's WASM compilers (Liftoff and TurboFan).
I'm entirely unfamiliar with V8's codebase/API (I compiled & linked it and followed some tutorials, though). There seems to be a v8::CompiledWasmModule class available, but it does not seem to expose access to generated x86/x64 instructions by either Liftoff or TurboFan.
WebAssembly - adding a new opcode describes the process of adding a WASM opcode to V8. Seemingly appropriate functions for WASM compilation/execution are available in the mentioned classes. Though, these seem rather deeply layered within the V8 codebase and would be difficult to access were I to link V8 as a library. Also, I'm unsure if this corresponds to Liftoff or TurboFan.
Could anybody familiar with the V8 codebase give me some pointers as to how I can access Liftoff and/or TurboFan's WebAssembly compilation module, as to obtain x86/x64 code?
To inspect generated code, you can run the d8 shell with the --print-wasm-code flag. You'll need either a debug build, or a release build with the v8_enable_disassembler = true GN arg.
There's no existing way to retrieve generated code via V8's API; so if that's what you want, then you'd have to add it. Keep in mind that V8 is not designed to be a standalone compiler, which means generated code assumes that it's going to run "inside V8", so if you wanted to use it for anything else, you'd have to make significant modifications.
Take the hello-world as an example.
I have couple of questions:
What does v8::Isolate do? Does it create an new thread
What does v8::Isolate::Scope do?
What does v8::HandleScope do?
What does v8::Local<v8::Context> do?
What does v8::Script::Compile do? Does it compile the js code directly to machine code?
Thanks your for your help!
See the official wiki:
An isolate is a VM instance with its own heap.
A local handle is a pointer to an object. All V8 objects are accessed using handles, they are necessary because of the way the V8 garbage collector works.
A handle scope can be thought of as a container for any number of handles. When you've finished with your handles, instead of deleting each one individually you can simply delete their scope.
A context is an execution environment that allows separate, unrelated, JavaScript code to run in a single instance of V8. You must explicitly specify the context in which you want any JavaScript code to be run.
These concepts are discussed in greater detail in the Embedder's Guide.
Once you've read the existing documentation, if anything is still unclear, please ask more specific questions.
Regarding (5): In current versions of V8, v8::Script::Compile compiles bytecode for V8's interpreter. In earlier versions, it compiled unoptimized machine code. The difference is an internal implementation detail that you don't need to worry about :-)
I'm trying to generate a static library from a compiled ELF file.
Previously, I've been able to generate the library by compiling my source code to object files, then passing those objects to avr-ar to successfully create my library. In order to reduce code space of the project, I've switched over to using link-time optimisations so save ~1.5 kB of space - however, in order to do so I end up passing all my source and header files to avr-gcc in one invocation and it spits out a .elf file.
I can't seem to get the -flto option working with the linker (I'm using a custom linker script) and compiler driver, otherwise I'd have the object files I need.
Is it possible to take this generated .elf and push it through ar to generate a library?
Problem Context:
This is related to this problem. I've written the shared libraries and bootloader section, and am using this linker script to set out my flash space. Here's the Makefile that drives all this - it's very hacked together.
Ideally, what I'd like to happen is to be able to compile my src/ director to separate object files in obj/, all with link time optimisation enabled to cut down on code space as much as possible but still leaving unused functions in the output (the shared library that is stored in flash is not fully utilised by the bootloader application, but may be linked against by the loaded applications). I'd then like to be able link those objects together to create a .elf and libbootloader.a. The elf is then used to generate a binary to flash to my AVR and the bootloader library is referenced when building user applications that refer to the stored library in flash space already. (Perhaps I want to just link against a list of symbols referencing the shared library section?)