View Issue Details

IDProjectCategoryView StatusLast Update
0001338XdebugFeature/Change requestpublic2016-12-11 23:28
Reportersidharth_kAssigned Toderick 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionno change required 
Product Version2.4.1 
Target VersionFixed in Version 
Summary0001338: Xdebug adds user opcode handlers for assignment even if if its not doing any tracing
DescriptionPlease look at https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L776

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

This is different from https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L674 or https://github.com/xdebug/xdebug/blob/d9985b228cca7678c037f23c2bd3774037061766/xdebug.c#L776 where it is checking XG(coverage_enabled) before adding any user opcode handlers.

Would it be possible for xdebug to _not_ add its own opcode handlers if its not doing tracing/ profiling?

My usage case is that I want to define my own user opcode handlers for every opcode (in a custom extension I'm writing) and I _still_ want xdebug available for debugging. I'm thinking that xdebug could successfully not override any opcode handlers except for maybe the silence handler (if coverage and profiling is not enabled)...

Alternatively I want to know a method in which I can set my own user opcode handlers and clobber those of xdebug. For some reason xdebug always runs zm_startup_xdebug() (i.e. MINIT) after my extension. This is even if I list my module _after_ `zend_extension=xdebug.so` line in my php.ini. Since xdebug runs afterwords it always succeeds in setting some user opcode handlers (i.e. mainly assign) which I don't want.

Can you suggest workarounds?

Summary:
- How can I clobber the user opcode handlers of xdebug in my extension. Will I still have usable debugging possible (if I'm not doing any code coverage or profiling)
- Alternatively can you make your user opcode handler addition conditional?
TagsNo tags attached.
Operating System
PHP Version7.0.5-7.0.9

Activities

sidharth_k

2016-08-17 11:49

reporter   ~0003678

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

sidharth_k

2016-08-18 08:54

reporter   ~0003680

****
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 ?

sidharth_k

2016-08-18 09:26

reporter   ~0003681

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 ?

derick

2016-08-18 09:49

administrator   ~0003682

| "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.

sidharth_k

2016-08-18 10:24

reporter   ~0003683

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?

derick

2016-08-24 15:07

administrator   ~0003689

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.

derick

2016-12-11 23:28

administrator   ~0004002

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.

Issue History

Date Modified Username Field Change
2016-08-17 11:34 sidharth_k New Issue
2016-08-17 11:49 sidharth_k Note Added: 0003678
2016-08-18 08:54 sidharth_k Note Added: 0003680
2016-08-18 09:26 sidharth_k Note Added: 0003681
2016-08-18 09:49 derick Note Added: 0003682
2016-08-18 10:24 sidharth_k Note Added: 0003683
2016-08-24 15:07 derick Note Added: 0003689
2016-12-11 23:28 derick Note Added: 0004002
2016-12-11 23:28 derick Status new => resolved
2016-12-11 23:28 derick Resolution open => no change required
2016-12-11 23:28 derick Assigned To => derick