Support Xdebug

[danielbachhuber]

Xdebug is a common developer tool. It would be nice to (optionally) support it.

Related work:

Nice-to-haves:

• [ php-wasm ] Follow-up on Xdebug #2315
• Debug PHP in browser Devtools (XDebug <-> CDP Bridge) #2288
• [ xdebug ] Add a mock @php-wasm/xdebug-bridge package #2398
• [ xdebug ] Bridge DBGP session with CDP server  #2402
• [ xdebug ] Add --experimental-devtools option in php-wasm CLI #2408
• [ xdebug ] Add --experimental-devtools option in Playground CLI #2411

Initial release:

• [ php-wasm ] Add xdebug shared extension to @php-wasm/node JSPI #2248
• [ php-wasm ] Add xdebug shared extension to @php-wasm/node ASYNCIFY #2326
• [ xdebug ] Add --xdebug option in php-wasm CLI and wp-playground CLI #2346

[adamziel]

There's a decent chance XDebug would just work if PHP was built with the right flags. Anyone keen to give it a try?

[ibrokemycomputer]

@adamziel I'd love to give this a go, but due to my full-time job it might be a slow process.

However... "boss man" has been wanting us to start supporting WP projects since we've become so heavily invested in the CMS for our agency clients. So, we'll see.

A couple of things stand out right off the bat:

• Depending on PHP version, the XDebug version needs to be either < || >= v3.
• While we can follow the basic/common flags, it might be tricky to account for all use cases if it cant be customized via a user-supplied/project-specific config

[ibrokemycomputer]

@adamziel Actually, I take that back. It seems like consideration for this is tied to Issue WordPress/playground-tools#28

[adamziel]

@ibrokemycomputer actually XDebug support would be fantastic regardless of WordPress/playground-tools#28. You are the most welcome to give it a go!

It would require updating the Dockerfile which builds PHP - you will notice some PHP version-dependent behaviors are already in there.

As for config flags, Playground’s php-wasm supports setting php.ini flags so that would only be a matter of supporting custom php.ini in wp-now.

[adamziel]

I was able to build xdebug extension to wasm:

$ git clone https://github.com/xdebug/xdebug.git
$ phpize
$ emconfigure ./configure
$ emmake make all
$ wasm2wat .libs/xdebug.so
// legit wat output

I had to patch the signature of these two functions and remove the final int from it:

• xdebug_trace_flamegraph_function_exit
• xdebug_trace_flamegraph_function_entry

I then tried to load it in @php-wasm/cli and got an error:

$ npx @php-wasm/cli -z ./.libs/xdebug.so
RuntimeError: Aborted(To use dlopen, you need enable dynamic linking, see https://github.com/emscripten-core/emscripten/wiki/Linking). Build with -sASSERTIONS for more info.

I looked for some answers on the dynamic linking page, but didn't find any.

Emscripten changelogs suggest dlopen is available for modules compiled with the -sMAIN_MODULE flag.

Edit: I used the -sMAIN_MODULE flag and now PHP isn't crashing anymore. Yay! It still doesn't load the extension, but the error is now different:

Failed loading .libs/xdebug.so:  (null)