[xdebug-dev] Re: What commands can be sent during run state?

Oh, btw: I would add breakpoint_update/breakpoint_remove into the allowed run state commands list.

On 7/19/16, 9:46 PM, "Jeffrey Tan" <jeffreytan[@]fb.com> wrote:

> I would also not mind adding breakpoint_set to the list of allowed commands, but anything that retrieves data, or variables, should probably not be in there, because of the mentioned performance reasons.
Thanks. I would like to add “breakpoint_set/breakpoint_get/breakpoint_list” three to the list of allowed commands at run state.

> I don't think that's a good idea, but you also don't need to. You can always issue a *break* command first. When the debugger engine then breaks, you can issue the breakpoint_* commands (or any other command).
That’s my original plan. But there is some problem for it: let’s say the target php thread is in the middle of step-over(which is in run state). User wanted to set breakpoint; so we issue “break” command to break the thread and then execute “breakpoint_get”. Finally, we want to resume the thread with original step-over. However, xdebug protocol has no way to say “resume previous continuation”. If we issue step-over at this point, it may be doing totally different step-over than original step-over. For example, the thread may be step-over function foo(), and our async break caused the thread to break in the middle of executing function foo(). After we breakpoint_get and resume step-over, hhvm will just do a step-over inside function foo() instead of finishing the original step-over foo().
Also, I can see no reason that breakpoint related commands can’t be accepted during run state.

> There isn't any list. Maybe we should make one?
Yeah, I think it would be clear if it states a command is allowed for run state or not.


On 7/19/16, 2:21 AM, "Derick Rethans" <derick[@]derickrethans.nl> wrote:

Hi Jeffrey,

(I've moved all the others to the xdebug-dev list as well, so they'll
see the reply too.)

On Mon, 18 Jul 2016, Jeffrey Tan wrote:

> The xdebug documentation is a bit vague on this part. What are the
> commands that can be sent during run state?
>
> Currently hhvm is implemented that only async “break” command can be
> sent during run state.

The protocol specs
(https://urldefense.proofpoint.com/v2/url?u=https-3A__xdebug.org_docs-2Ddbgp.php-23packet-2Dcommunications&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pIJ4qXJ_cgV3AJQeM1tpu4D-ejvcyvkdOHNwUTK1OGQ&m=4CogbcQB7eJjJlwHnOJNoNrAljPWkgh70SexR8qqGd4&s=_IYgMXChl9wvC0rVqqPnJsJpURo0IofF8qMW-Hphs8s&e= ) say:

        If the debugger engine *supports asynchronous commands*, the IDE may
        also send commands while the debugger engine is in a 'run' state.
        These commands should be limited to commands such as the 'break' or
        'status' commands for performance reasons, but this protocol does
        not impose such limitations. The debugger engine MUST respond to
        these commands *prior* to responding to the original 'run' command.

However, the intention is that the sending of async commands is limited
to the two mentioned in the above paragraph. HHVM currently just doing
an async break, sounds like it is in the spirit of the protocol. I am
happy to amend the wording so that this is explicitly mentioned in the
protocol specs.

I would also not mind adding breakpoint_set to the list of allowed
commands, but anything that retrieves data, or variables, should
probably not be in there, because of the mentioned performance reasons.


> This caused problems in our IDE because user may set breakpoints in
> run state, but all the breakpoint_xxx commands are ignored by hhvm.
> The result is that these “run state” set breakpoints are not taking
> effect.
>
> I am going to change hhvm xdebug implementation to allow
> breakpoint_xxx commands in run state. Let me know if you agree with
> this.

I don't think that's a good idea, but you also don't need to. You can
always issue a *break* command first. When the debugger engine then
breaks, you can issue the breakpoint_* commands (or any other command).

> Is there a white/black list of commands that allowed/not-allowed in
> run state? Thanks.

There isn't any list. Maybe we should make one?

However, don't expect debugger engines *or* IDEs
to support async mode. You *have* to test for that with a feature_get
command (https://urldefense.proofpoint.com/v2/url?u=https-3A__xdebug.org_docs-2Ddbgp.php-23feature-2Dnames&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pIJ4qXJ_cgV3AJQeM1tpu4D-ejvcyvkdOHNwUTK1OGQ&m=4CogbcQB7eJjJlwHnOJNoNrAljPWkgh70SexR8qqGd4&s=eGgJQnixqZaXn1ElbcuAeT6m-n3qYXpO1fx8z-sma7U&e= ). If you want
the HHVM debugger engine to be used with standard available IDEs, you
can not rely on these IDEs to support asynchronous communications.

cheers,
Derick

--
https://urldefense.proofpoint.com/v2/url?u=https-3A__derickrethans.nl&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pIJ4qXJ_cgV3AJQeM1tpu4D-ejvcyvkdOHNwUTK1OGQ&m=4CogbcQB7eJjJlwHnOJNoNrAljPWkgh70SexR8qqGd4&s=uXhVYhwhdJmfp_m_2V6AfdW4WFxsNi_OT1VULEE_AWE&e= | https://urldefense.proofpoint.com/v2/url?u=https-3A__xdebug.org&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pIJ4qXJ_cgV3AJQeM1tpu4D-ejvcyvkdOHNwUTK1OGQ&m=4CogbcQB7eJjJlwHnOJNoNrAljPWkgh70SexR8qqGd4&s=VJZvGTGPAYjM0r6zqBAegDweUq7RO7L1WSz862KEnhs&e= | https://urldefense.proofpoint.com/v2/url?u=https-3A__dram.io&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pIJ4qXJ_cgV3AJQeM1tpu4D-ejvcyvkdOHNwUTK1OGQ&m=4CogbcQB7eJjJlwHnOJNoNrAljPWkgh70SexR8qqGd4&s=1SAoag3xdNRKk0DS8_h1O8SRO297vNfSnHqbUnPpym8&e=
Like Xdebug? Consider a donation: https://urldefense.proofpoint.com/v2/url?u=https-3A__xdebug.org_donate.php&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=pIJ4qXJ_cgV3AJQeM1tpu4D-ejvcyvkdOHNwUTK1OGQ&m=4CogbcQB7eJjJlwHnOJNoNrAljPWkgh70SexR8qqGd4&s=vK_UoEeooUYRisxIf_ngCi-pp3ik1Nh7cURzQhB1788&e=
twitter: @derickr and @xdebug



Received on Wed Jul 20 2016 - 16:47:14 BST