On Sun, 24 Mar 2024 at 15:38:26 +0000, Thorsten Glaser wrote:
> Simon McVittie dixit:
>
> >(Or of course porting libunwind to the remaining architectures would
> >be another obvious way that porters could address this.)
>
> Definitely. All three are valid possibilities.
>
> >Another possible way to attack this, particularly if libunwind is
> >functionally necessary in sysprof (I don't know whether it is), would
> >be to limit sysprof integration to those architectures where developers
> >are practically likely to want to carry out profiling/optimization work.
>
> I think that this is probably easier to do within sysprof if it has
> multiple users, unless all users have something like autoconf and
> check for presence and just don't use it if absent.
There are only a few users of sysprof-capture, and for bootstrappability
we will likely want them to at least be able to disable that dependency
with a build-profile anyway, because there's a circular build-dependency
(sysprof <-> GTK) - which can be broken from either end, but does need
explicit action to break.
Having looked a bit more closely at the use of libunwind in src:sysprof,
it has three major parts:
- libsysprof-capture is the part that various GNOME libraries optionally
link, in order to provide better context/traceability when the
application is being profiled. It doesn't need GLib or libunwind.
- libsysprof is required by development tools/IDEs like the sysprof
application and gnome-builder, and is the part that profiles the
application under test and prepares reports on where it's spending
most of its CPU cycles. It requires libunwind and GLib, and cannot be
built without libunwind (which makes sense to me, because without the
ability to interpret backtraces, it has no value).
- sysprof is a GUI application for developers who want to profile their
app or library. It needs libsysprof and therefore libunwind.
For libsysprof and the sysprof application, I think this is certainly
wontfix. If you want IDEs like gnome-builder to have their full
functionality (including use of sysprof-based profiling) on a particular
architecture, then porters will have to make libunwind available on that
architecture. Conversely, if you aren't interested in sysprof-based
profiling on an architecture, then there's no real need for any of
src:sysprof to exist on that architecture.
So the best that is likely to be possible in src:sysprof without libunwind
is to compile only libsysprof-capture, and not libsysprof or the sysprof
application. I'm not convinced that would actually be practically useful -
if libsysprof-capture is available but libsysprof isn't, then the library
or application will be reporting better context/traceability about where
it's spending its time, but nothing will be reading that information,
making it seem somewhat pointless.
The bar for whether any of src:sysprof is practically useful is probably
something like "you would genuinely run this architecture on your
main laptop/workstation and use it for daily app/library development in
preference to any other architecture", so we're probably already building
it on lots of architectures where nobody is really using it (for example
I find it hard to imagine choosing s390x as a day-to-day development
environment). In practice amd64 and arm64 would likely be a 99% solution.
I've pushed a commit to gtk4 to disable the libsysprof-capture dependency
and integration on architectures where it isn't available, and I think
that's probably a good approach in the 5 other source packages with
a similar dependency. At the time of writing, sysprof is available on
all release architectures, plus powerpc and ppc64. I'm not intending to
upload gtk4 right now, but this change will be in the next gtk4 upload
unless there's a showstopper problem with it.
smcv
