BTW thanks in advance for your consideration on this. Sincerely -- Sidharth

EDIT to original ticket

There was an error in my original ticket. Please read the first lines of my ticket as

"Please look at https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L744

You will notice that xdebug is unconditionally adding its own opcode handlers."

I erroneously was referring to line 776 when I actually wanted to refer to line 744.

=============
I was able to get this to work. The solution was simple in retospect. I made my php extension a zend extension and put it after the zend_extension=xdebug.so in the ini file. Now my zend extension loads after xdebug and is able to set its own opcode handlers for all opcodes.

So the question I have at this point is: Is xdebug still usable as a debugger in this case? Note that I'm not interested in tracing so the lack of those user opcode handlers in xdebug should not make a difference -- or should it?

Additionally, I was wondering why you are unconditionally overriding assignment opcodes unlike the many other opcodes in which you always check XG(coverage_enabled). Why don't you have something like XG(trace_enabled) or something like that starting at https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L744 ?

A further update.

Running after adding my own user opcode handlers (and clobbering the unconditionally added handlers by xdebug for tracing) by my custom zend extension seems to leave xdebug fully functional for debugging (i'm not interested in tracing/code coverage).

So finally, I'm just hoping to know if there is any edge case that might cause me problems. Cause there may be a reason why you didn't do XG(trace_enabled) at https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L744 ?

| "So the question I have at this point is: Is xdebug still usable as a debugger in this case?"

As a debugger, probably yes. As a code coverage analyser, or tracer, probably (or rather, likely) not.

| "So finally, I'm just hoping to know if there is any edge case that might cause me problems. Cause there may be a reason why you didn't do XG(trace_enabled) at https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L744 [^] ?"

Because a user can use xdebug_start_trace() anywhere in the code, and hence, the opcodes should already been redirected for that to work.

Thank you so much for response. Very useful.

Ok I understand why those assignment opcodes are unconditionally overridden now. Are there other edge cases that we haven't considered? Like overriding silence handlers... is anything else likely to affect debugging generally? Probably not I'm guessing/hoping.

On a related note: if a user initiates tracing via xdebug_start_trace() you could check something like XG(trace_opcodes_were_overriden). If the variable is false then you could do the user opcode overriding and then set the variable to true. You could call this "lazy overriding".

The advantage of this approach (apart from the fact that xdebug doesn't change things internally more than necessary) is that performance could be marginally better. A large number of statements are assignment statements in imperative code and if a user opcode handler is not triggered for them we could make php running under xdebug faster. Or am I missing something else here? (Perhaps its not wise to set user opcode handers from a PHP internal function??).

Alternatively it might be a good idea to have a php.ini option xdebug.wont_use_tracing=1 to disable tracing all together. This would achieve the same effect of making php under xdebug a bit faster?

This is just a suggestion and I wonder if these two ideas might have any practical performance benefits?

Probably not much, but it's not easily possible to do "lazy overriding". This is generally not supported, and probably not very stable.

As a performance thing, it is something I want to look at. But too much work :-/

I can probably make a setting that does make Xdebug not override anything, but that would also mean shutting down features. What I want to do at some point, is having different modes in Xdebug - where each does only the things strictly necessary to function.

I am closing this issue, as there is no actionable content in it. Of course I want to make Xdebug faster, but right now, there is nothing in this bug report about something specific.