On Fri, Apr 23, 2021 at 4:42 PM Joey Allen <allenjoe...@gmail.com> wrote:
>
>
> Hello all,
>
> We are working on a research project and one functionality we are trying to
> implement is to hook the entry point of a JS function, and then backtrack to
> determine the scope in which the input parameters for this function were
> created.
>
> To implement hooking the entry point of a function, we used an approach
> similar to the --trace flag, and it is working well. However, we are facing
> issues when implementing the "backtracking" to determine the creation scope
> of the input parameters.
>
> To provide an example in what we are trying to achieve, I have provided a
> sample program below. In this sample program, the goal of our instrumentation
> will be to hook the send function and eventually learn that the input
> parameter, data, was created in the sendDatafunction.
>
> Sample Program:
>
> function send(data) {
> console.log(data)
> }
>
> function preSend(data) {
> send(data)
> }
>
> function sendData() {
> var data = "input-data"
> preSend(data)
> }
>
> sendData()
>
> Our Current Approach
>
> Our current approach to determine the creation scope is to iterate the JS
> call stack, and then access the context for each function. Using the context,
> we then are calling context.scope_info() to reference the ScopeInfo, which
> will hopefully provide information related to the variables created in this
> scope. The intuition behind this approach is based on the comment in
> `src/objects/contexts.h` which suggests that at runtime a parallel 'context
> stack' is created.
>
> However, we have found that when walking the Javascript stack, when we check
> the context of each function, the context() method always returns a
> NativeContext, which is the same for each function. For example, in the
> snippet below, the object returned by it.frame()->context() is the same for
> every function on the stack for the sample program above.
>
> Isolate* isolate = Isolate::Current();
> JavaScriptFrameIterator it(isolate);
> while (!it.done()) {
> std::cout << "Function: " << it.frame()->function() << std::endl;
> std::cout << "Context: " << it.frame()->context() << std::endl;
> }
>
> Can anyone provide any suggestions on how to access the scope of a specific
> function, and on the feasibility of this approach? We are also open to other
> approaches for achieving this.
>
> thanks,
> Joey
Untried, but does it.frame()->function().context() give the expected result?
As a general observation: you can probably use the inspector protocol
for this (see include/js_protocol.pdl, search for CallFrame). I
suspect your current approach won't work for optimized code. The
inspector takes cares of deoptimizing what needs deoptimizing.
--
--
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/v8-users/CAHQurc-3-G5fgw7seGGHBg3%3DNC9PRw0yNXyBf2_yQTsBi-HL%2Bw%40mail.gmail.com.
