mirror of
https://github.com/LibreOffice/core.git
synced 2025-07-23 04:42:03 +00:00
e4b24dba07
...which had been replaced with -gsplit-dwarf in
8ecdff7ac3 "Modernize wasm debug symbol
generation". But -gseparate-dwarf and -gsplit-dwarf are apparently orthogonal:
-gseparate-dwarf adds a supplementary *.wasm.debug.wasm (whose relative URL is
recorded in an external_debug_info section in the original *.wasm), and the
original *.wasm and the supplementary *.wasm.debug.wasm have exactly the same
content, except that only the supplementary *.wasm.debug.wasm contains any of
the .debug_* sections (and only the original *.wasm contains the
external_debug_info section). That way, the original *.wasm stays small (so
that it does not exceed any limits of the browser's JS WebAssembly instantiation
machinery), while the browser's debugger (like Chrome's "C/C++ DevTools Support
(DWARF)" extension) uses the supplementary *.wasm.debug.wasm. This is
especially relevant when building LO with e.g. -fsanitize=address, where the
resulting soffice.wasm would otherwise easily grow too large.
-gsplit-dwarf, on the other hand, leaves certain debug information in .debug_*
sections in the original *.wasm and offloads further debug data to an auxiliary
*.wasm.dwp (which the browser's debugger will then load and use in addition to
using the original *.wasm's debug information). When combined with
-gseparate-dwarf, there's an overall three files now: the original *.wasm (used
by the browser's JS WebAssembly instantiation machinery; lacking any debug
information), the supplementary *.wasm.debug.wasm (used by the browser's
debugger; containing some debug information), and the auxiliary
*.wasm.debug.wasm.dwp (used by the browser's debugger; containing further debug
information). (One might assume that when using -gseparate-dwarf there would be
no benefit from additionally using -gsplit-dwarf. But when I tried that with at
least Chrome version 138.0.7204.100 and the "C/C++ DevTools Support (DWARF)"
extension version 0.2.5854.1, it would still sometimes fail with
> [C/C++ DevTools Support (DWARF)] Loading debug symbols for http://localhost:6931/soffice.wasm (via soffice.wasm.debug.wasm)…
> [C/C++ DevTools Support (DWARF)] Failed to load debug symbols for http://localhost:6931/soffice.wasm (TypeError: Failed to fetch)
and the emrun server reporting
> 127.0.0.1 - - [15/Jul/2025 22:41:58] code 404, message File not found: /home/sberg/cowasm/core/workdir/installation/LibreOffice/emscripten/soffice.wasm.debug.wasm.dwp
> 127.0.0.1 - - [15/Jul/2025 22:41:58] "GET /soffice.wasm.debug.wasm.dwp HTTP/1.1" 404 -
making it look like it wanted to access a non-existing auxiliary
soffice.wasm.debug.wasm.dwp for some unclear reason. So, at least for now, it
looks better to just use a setup that provides that auxiliary file anyway.)
Change-Id: I72352479c864c8d89cc63cc228aa676c7c2d8ccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187953
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Native Install-Set Creation
This is where you will find your natively packaged builds after the build has completed. On Windows these would live in:
workdir/*/installation/LibreOffice_Dev/native/install/en-US/*.msi
for example (nothing like a few long directory names before breakfast).
Also generates .ini files for the instdir/ tree (which are unfortunately
duplicated for now between instsetoo_native/CustomTarget_setup.mk and scp2).