WordPress/wordpress-playground

Support Xdebug

danielbachhuber opened this issue · 9 comments

danielbachhuber commented

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

Done is:

  • It's possible to use Xdebug with wp-now.
adamziel commented

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 commented

@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 commented

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

adamziel commented

@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 commented

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)
  • 👍2
adamziel commented

I've built a minimal dlopen() example that works with Emscripten:

https://gist.github.com/adamziel/9c7d3302407294e12d9c1d1eaa54cdba

So it can work, yay! The key is indeed building with -sMAIN_MODULE.

The question now becomes: What goes wrong when we use it with PHP?

  • ❤️2
adamziel commented

Other than step-debugger, XDebug seems to be working in #831.

Anyone following this issue – would you rather get such a limited version of XDebug early and the step-by-step debugger support in one of the next iterations? Or is that step-by-step debugging the sole reason you're interested in XDebug?

alexstandiford commented

For me, step debugging is a pretty key component in that, but just having formatted var_dump would be a pretty big win, in my opinion.

I don't see any reason to hold off until it's all included, personally.

  • 👍2
  • ❤️2
adamziel commented

Perfect! Let's not block the XDebug PR on the step debugger support. I can't promise any timeline, but the next step here is cleaning up and merging that PR 🔥

  • 🎉3