HI,

I will try to answer your questions, but maybe some more background on how
you use the various debuggers. When you mention D8 I assume you are using it
as a debugger front end through the --remote-debugger flag, and when you
mention Eclipse I assume you are using the Google Chrome Developer Tools
Eclipse plug-in (http://code.google.com/p/chromedevtools/). However with
Ares are you debugging your application or are you just comparing debugging
of an WebOS application to the other V8 debuggers?

1) This sounds right to me. Can you provide some more information in the D8
issue? If I run two terminals with

$ ./d8 --debugger-agent
$ ./d8 --remote-debugger

Then in the debugger type

dbg> b test.js:4

and load test.js in the shell

v8> load("test.js")

I get a break on line 4 with the following test.js:

function f() {
  a=2;
}
a=1;
f();

What do you mean with "only resolve symbols against one context"? Is it
related to evaluation of JavaScript expressions in the debugger, or is it
related to mapping breakpoints of the form resource_name:line to running
code?

2) The purpose of v8::Debug::SetDebugMessageDispatchHandler(...) callback is
to ensure that debugger commands are being processed when the V8 host might
not be running JavaScript. One way to do that is to just execute some
JavaScript from the host. Given that the --debugger-auto-break flag is set
(defaults to true) pending debugger commands will break JavaScript execution
and process the debugger commands. Another way of processing debugger
commands is to call v8::Debug:: ProcessDebugMessages() which is what the
lineprocessor.cc sample does. When the debugger commands are processed they
will be processed in the context which is active. If JavaScript is executed
the context will be the one currently active whereas when using
v8::Debug:: ProcessDebugMessages()
the context is determined by the host prior to the call. Some debugger
commands are independent and some are not. As you mention the 'evaluate'
commmand is of cause context dependent, and will be executed in whatever
context is active.

So, how to chose the right context for processing debugger commands will be
application specific. In Chrome each page has a number of context - one for
each frame, and there the natural choice is the context for the top frame
for the tab being debugged. If an application has several different contexts
where a current debugging task is only interested in one of these there need
to be some additional logic in the host to determine the context. If several
contexts are running the same script break points additional logic might
also be required in the front end to ignore breaks from some contexts.

3) It should not be required to having entered a context before enabling the
debugger agent or setting up callback handlers. However it looks as it there
is an issue with the wait_for_connection flag not having the desired effect.
I have opened issue http://code.google.com/p/v8/issues/detail?id=854 on
this.

Regards,
Søren

On Thu, Aug 26, 2010 at 22:27, DAldridge <[email protected]> wrote:

> I've been thrown into a codebase that has embedded V8 and appears to
> be functioning (in terms of JavaScript execution) fine; however, I'm
> trying to enable debugging support and am seeing differing behaviors
> in D8 as compared to Eclipse and Palm Ares.  I'm guessing it's related
> to how I've enabled the debugging, as D8 doesn't exhibit the same
> behavior when run against the LineProcessor sample.
>
> In this codebase, we have multiple modules (DSO on Linux, .DLL in
> Win32, all linking dynamically to V8) running in our main process,
> each with their own thread which creates/manages/uses its own V8
> Context and GlobalTemplate. All of them appropriately (from what I can
> tell) use v8::Lockers to synchronize V8 access.
>
> I am attempting to use v8::Debug::SetDebugMessageDispatchHandler(...)
> and v8::Debug::EnableAgent(...) in accordance with the "--main-cycle-
> in-cpp" and "--callback" implementation in the LineProcessor sample.
>
> Question 1:
>
> Should debugging JS in this scenario pose no problems? The behavior
> I'm seeing with D8 is that I cannot hit a breakpoint set on an
> expression outside of a function (e.g. global/file-scope stuff), and
> it can only resolve symbols against one context.  Neither the Eclipse
> JS plugin nor Ares have these issues.
>
> Question 2:
>
> The LineProcessor sample only uses a single context, so its
> implementation of the handler for the debug message dispatch callback
> simply enters that context.  The comments in the method mention that
> other action is required if more contexts are used (presumably to pick
> one so that "evaluate" works - is this correct?).  How would one go
> about choosing the "correct" context?
>
> Question 3:
>
> Empirically, it seems that a Context must be entered prior to enabling
> the agent or setting the debug message dispatch handler.  If that
> isn't done (i.e. you try to set up the debug support before any
> contexts are created), the "wait for connect" behavior of the agent
> doesn't seem to work.  Is this correct?  Browsing through the V8 code,
> is looks like debug stuff happens in its own Context, so I don't
> understand why you'd need to create/enter one prior to enabling
> debugging.  If you do indeed need to create/enter a context, does it
> matter which one?
>
> Thanks,
> -David
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to