Relay correct source paths in DWARF debug info

[brandonpayton]

Motivation for the change, related issues

It is possible to build php-wasm with DWARF debug info today, but actually using the debugger to step through source lines requires additional configuration to map original source file paths (from Docker) to actual source file paths in the host OS.

The purpose of this PR is to set the correct source paths at build time so folks can debug php-wasm without additional configuration.

This is not just a matter of convenience. Some debuggers (VSCode) only allow a single path mapping, so we cannot step into source files from different directory subtrees at the same time (for example, php-src and php_wasm.c). It would be simpler, faster, and more complete for debugging with DWARF to work out of the box.

Implementation details

This PR adds compilation flags like the following to establish compilation dir and source file paths relative to that:

• -fdebug-compilation-dir=${OUTPUT_DIR_FOR_SOURCE_MAP_BASE}/${PHP_VERSION_ESCAPED}/
• -fdebug-prefix-map=/root/php_wasm.c=${DEBUG_OFFSET_TO_PHP_WASM_PACKAGE}/compile/php/php_wasm.c

Testing Instructions (or ideally a Blueprint)

For php-wasm/node

• Build a version of PHP for php-wasm/node
• Set a breakpoint at the beginning of run_cli() in php_wasm.c
• Run the "Debug PHP-WASM CLI with DWARF Symbols" target in VSCode
• Select the version of PHP built with debug info
• Observe you hit the breakpoint
• Step through execution and into a php-src file to demonstrate that mapping works

For php-wasm/web

• Build a version of PHP for php-wasm/web
• Run npm run dev
• Launch Chrome Canary
• Install the C/C++ DevTools Support (DWARF) extension if you don't already have it
• Navigate to http://127.0.0.1:5400/website-server/
• Select the version of PHP built with debug info
• Open the devtools Sources tab
• Try to open php_wasm.c. If the file shows up, it indicates there are DWARF mappings to that file.
• Try to open zend_alloc.c. If the file shows up, it indicates the DWARF mappings to PHP source files are working.
• Set a breakpoint at an interesting place and try to hit it.

[brandonpayton]

Currently, this PR sets the correct source maps for php-src and php_wasm.c.

⛔ Some things aren't implemented yet:

• Mapping for proc_open.c (we have multiple versions, and one is chosen at compile time)
• Mapping for php-extensions like sqlite.

[brandonpayton]

Making these paths absolute helped the php-src mapping to be applied properly.

[brandonpayton]

This was removed mistakenly by #2231. Without disabled ASSERTIONS, php-wasm/web builds seem to fail to load due to assertion errors.

[brandonpayton]

Note:
The test instructions for php-wasm/node and php_wasm.c only seem to work with JSPI enabled. With an Asyncify build, breakpoints in php_wasm.c become breakpoints in php_8_3.wat (WebAssembly Text format). I wonder if it has to do with Asyncify instrumentation.

[brandonpayton]

I implemented building libsqlite3 with DWARF debug info and, using a JSPI build, tested that it was possible to hit breakpoints in both php_wasm.c and sqlite3.c in the same build with no additional config.

[brandonpayton]

To build libsqlite3 with DWARF debug info:

cd packages/php-wasm/compile
make libsqlite3_jspi WITH_DEBUG=yes

Then build php-wasm/node with that libsqlite with:

npx nx recompile-php:jspi php-wasm-node -- --PHP_VERSION=8.3 --WITH_DEBUG=yes

[brandonpayton]

Let's go ahead and mark this as ready for review because it is better than what we have today.

Once we have this, I plan to write instructions for debugging php-wasm. Compared to before this PR, it should be a lot easier to get started.

[adamziel]

Really good work, thank you @brandonpayton !