Source: webkit2gtk Version: 2.52.6-1 Severity: minor Tags: upstream I have discovered from reading https://docs.webkit.org/Build%20%26%20Debug/DebuggingOnTheCommandLine.html that WebKit, like many major projects, has Python scripts for GDB and LLDB to enhance the experience of debugging WebKit. For example the GDB one provides "pretty-printers" for WebKit data structures. This can be found at https://github.com/WebKit/WebKit/blob/main/Tools/gdb/webkit.py and it ought to be available in a Debian package of some kind. This should be installed in a way so that GDB can discover it.
GDB on Debian says > List of directories from which to load auto-loaded scripts is > $debugdir:$datadir/auto-load. > The directory where separate debug symbols are searched for is > "/usr/lib/debug". > GDB's data directory is "/usr/share/gdb". For Python in particular https://sourceware.org/gdb/current/onlinedocs/gdb.html/Python.html says > Python scripts used by GDB should be installed in data-directory/python, > where data-directory is the data directory as determined at GDB startup (see > Data Files). Therefore this webkit.py file should be available at /usr/share/gdb/python/webkit.py for example. I would double-check if this is still best practice, because as I will describe, other Debian packages handle this differently. The way that some other Debian packages are doing this is by installing the script so that it has a name corresponding to the shared object it is intended to affect, and therefore GDB can pick up on them: libc6-dev:amd64: /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libc.so.6-gdb.py libgstreamer1.0-dev:amd64: /usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0.2602.0-gdb.py libglib2.0-dev:amd64: /usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.8400.4-gdb.py libglib2.0-dev:amd64: /usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.8400.4-gdb.py This convention is documented at https://sourceware.org/gdb/current/onlinedocs/gdb.html/objfile_002dgdbdotext-file.html An alternative option, to prevent having multiple copies of the same script, is to use a special ELF section in the shared objects to tell GDB about a path that can be used to *access* the Python script in the source tree. This is articulated at https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005fscripts-section.html One could set the .debug_gdb_scripts ELF section to reference Tools/gdb/webkit.py for example, and then someone debugging WebKitGTK on Debian and who has the source tree handy may pick that up. Note that this is less helpful in Debian, as our debuginfod instance isn't capable of serving source files at the moment. It's also possible to use the ELF section to include the GDB script directly, which is appealing since it's not very long on this occasion. (The LLDB code at https://github.com/WebKit/WebKit/tree/main/Tools/lldb looks much more involved.) Upstream also has a Valgrind suppressions file https://github.com/WebKit/WebKit/blob/main/Tools/Scripts/valgrind/suppressions.txt which will be helpful to folks developing WebKitGTK applications on Debian, and which should likewise be installed at a canonical system-wide location so it can be used easily by folks who don't know they need it yet. The biggest hurdle here is that none of these files are shipped in the WebKitGTK source tarball that is generated. Perhaps folks using these features so far are mostly doing new development on WebKit itself from a Git checkout, and making these helpers installable by downstream distributors hasn't been a priority. In Debian it's normal to package these files, and we should do so, somehow. -- System Information: Debian Release: 13.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.101+deb13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
signature.asc
Description: This is a digitally signed message part
