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.