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 :-)
Related
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.
When using CSScript.Evaluator.Reset(), will this reset anyone else that is currently using the same script or build?
Another way of asking my question.
script = CSScript.Evaluator.LoadCode(scriptString);
If another user came thru and called the same code, but an error occurred.
Would the original compile still be good and safe?
Also CSScript.Evaluator.AutoResetEvaluatorOnError = true, this does not seem to be working.
After i cause an error in the code, then fix it. The compile will not work til i reset my app, or use Reset().
Using Reset is working, But that's the reason for my initial question.
I am using CSScript.Evaluator.LoadCode and looking at CSScript.Evaluator.LoadMethod, but getting the same issues.
These are not huge scripts, but may run in large batches or loops.
Not against unique naming, cause i will have build for every run anyway.
But i'm not sure the cache is working either.
Where is the location of the cache folder, when CSScript.CacheEnabled is enabled?
Would the original compile still be good and safe?
Yes it would as when you hold the reference to the compiled object it is YOURS. I is good even if you destroy the compiler.
Also CSScript.Evaluator.AutoResetEvaluatorOnError = true, this does not seem to be working.
This setting triggers so cold SoftReset, which is different to the Reset only by re-referencing the assemblies and re-creating the CompilerSettings object. It the time of the initial implementation SoftReset was sufficient to fully clear Mono.Evaluator. I will need to check may be it is not the case any more. I will let you know the outcome.
Where is the location of the cache folder, when CSScript.CacheEnabled is enabled?
The caching doesn't cover Mono Evaluator as the all assemblies are in the memory and cannot be cached.
Everything that is accessed through CSScript.Evaluator.* applicable to the Mono compiler and everything that it accessed through CSScript.* is a CodeDOM compiler, which indeed implements caching mechanism.
I was wondering if there is a quick and effective way to remove all the unused variables (local, instance, even properties) in xcode... I am doing a code cleanup on my app and if I knew a quick way for code refactoring it would help me a lot...
Thanks...
It's being a long time since you made your question and maybe you found an answer already, but from an answer to a related question:
For static analysis, I strongly
recommend the Clang Static Analyzer
(which is happily built into Xcode 3.2
on Snow Leopard). Among all its other
virtues, this tool can trace code
paths an identify chunks of code that
cannot possibly be executed, and
should either be removed or the
surrounding code should be fixed so
that it can be called.
For dynamic analysis, I use gcov (with
unit testing) to identify which code
is actually executed. Coverage reports
(read with something like CoverStory)
reveal un-executed code, which —
coupled with manual examination and
testing — can help identify code that
may be dead. You do have to tweak some
setting and run gcov manually on your
binaries. I used this blog post to get
started.
Both methodologies are exactly for what you want, detecting unused code (both variables and methods) and removing them.
I want to add usage statistics for a .NET 4.0 library I write on CodePlex.
I try to follow the step described here but my problem lies with the fact that what I write is a library and not an application.
One of the steps is put the Setup and Teardown attributes. I thought about adding the Setup attribute on a static constructor or a different place that will run once per usage of the library. My problem lies with the Teardown attribute that should be placed on code that ends the usage. I don't know where to put this attribute.
Is it possible to get usage statistics on a library?
Maybe I can register on an event that will fire when the application unloads the dll?
This looks like a typical honeypot giveaway, designed to commit you to the retail edition of their obfuscator. It's a tough business, few play this game better than Preemptive. Yes, using attributes is not going work for a library. The only possible candidate would be a finalizer. And you do not want your code to contact some website while the finalizer thread is running.
Take a look at the retail edition of their product. I bet it has a way to invoke the methods that are normally injected by their obfuscator directly. The class constructor is an obvious candidate for "Setup". An event handler for the AppDomain.ProcessExit event could be a possible location for the "Teardown" call. This also might avoid having to run the obfuscator at all, not undesirable in an open source project.