binutils 2.43, build-ids, systemd, drkonqi

[Harald Sitter]

Ahoy ahoy

I have a number of topics FYI.

Pretty much all relating to
https://invent.kde.org/plasma/drkonqi/-/merge_requests/323

TLDR: in 6.4 we will likely have a drkonqi that can operate with
magnitudes less memory, but at the same time relies heavily on
build-ids in libraries, and also heavily uses systemd APIs

# binutils 2.43

there was a bug in binutils 2.43 that resulted in build-ids not ending
up in core files. that is going to become a major headache because the
low memory mode kind of requires build-ids to make sure the correct
libraries get loaded. we very much want to make sure libraries haven't
changed as part of live-upgrades and build-ids seem the best way to
achieve that. it might make sense to make sure your package archives
have been rebuilt with ld 2.44 before plasma 6.4 (at least all the
major stuff used by kde/qt if nothing else)

https://sourceware.org/bugzilla/show_bug.cgi?id=32100

# build-ids

build-ids are going to be pretty much required. if you haven't
implemented them yet you should or your users possibly won't be able
to file crash reports (in fact, that is already largely the case
because 99% of crash data comes in via sentry and that workflow relies
on build-ids)

# systemd

I understand this one is a bit contentious but we are moving ever
closer to a point where the experience that uses systemd is 100% more
useful than the old fork based just-in-time approach. it's
increasingly hard to QA drkonqi because the feature sets are so
different between the JIT debugger and the coredump debugger. I am not
sure how to deal with this for freebsd but I think long term we will
have to get compatibility rigging for select systemd functionality or
we just can't consume crashes.

specifically as it stands right now:

- the entire coredump machinery as it forms the backbone of reliable
crash handling. this in particular means something needs to catch
crashes, store them as cores for consumption in gdb, provide a
coredumpctl-compatible CLI to extract the cores again
- https://www.freedesktop.org/software/systemd/man/latest/sd-journal.html
for extraction of coredumps generated by the coredump machinery as
well as data from the application logging framework
- https://www.freedesktop.org/software/systemd/man/latest/sd-event.html
for the new memory pressure/fencing system to a) maintain a
lightweight eventloop and b) fire pressure events into that loop
- select pieces of the systemd unit API in particular to read and set
the properties MemoryCurrent and MemoryHigh which should enforce
memory constraints on the process group

the trouble here is that systemd is essentially providing us with
abstraction from the low level shenanigans so I am not sure what to do
instead. thoughts welcome.

HS