Hi Ben,
Sorry for the late response. Thanks for pointing us in the right
direction. After reviewing the inspector code related to CallFrame, we
found that the inspector is using the DebugScopeIterator
(v8/src/debug/debug-scope-iterator.h) to gather scope information, and we
were able to use it to extract this information.
Thanks for the help,
Joey
On Monday, April 26, 2021 at 5:06:18 AM UTC-4 Ben Noordhuis wrote:
> On Fri, Apr 23, 2021 at 4:42 PM Joey Allen <allen...@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/1cba6e94-0601-460c-a5a8-59efba47fd7bn%40googlegroups.com.
