The PR branch HEAD was 0705708 at the time of this review club meeting.
Notes
Userspace, Statically Defined Tracing (USDT) allows us to hook into tracepoints during Bitcoin
Core runtime. Once a tracepoint is reached, it can pass data about process internals to a
userspace script for further processing. This is great for observability and allows for debugging,
testing, and monitoring. See “Userspace, Statically Defined Tracing support for Bitcoin
Core” for more background information.
Initial build support for tracepoints was added in
#19866. The tracepoints (e.g. TRACE1(context,
name, arg0)) use (see
src/util/trace.h) the
DTRACE_PROBE macros (see
systemtap:includes/sys/sdt.h#L486)
from Systemtap under the hood. This requires the sys/sdt.h
header to be present during compilation. If not present, ENABLE_TRACING will not be set to 1 in
configure.ac,
and no DTRACE_PROBE’s are used.
On Ubuntu/Debian, for example, the sys/sdt.h headers are included in the systemtap-sdt-dev
package. If this package is installed, binaries with DTRACE_PROBE tracepoints will be built.
Developers wanting to use the tracepoints can build the binaries themselves.
However, tracepoints should ideally be included in release builds. This allows, for example,
hooking into the tracepoints of production deployments. No custom binaries (which might behave
differently) need to be compiled and deployed to trace Bitcoin Core.
Did you manage to build a bitcoind binary including the tracepoints (see “Listing available tracepoints” in doc/tracing.md)? Did you do a GUIX build?
For GUIX builds, why do we need to add the Systemtap sys/std.h header as a dependency instead of using the header file avaliable on the GUIX build host system?
In which build step is ENABLE_TRACING set? Under which condition is it set? What happens when it’s set to 1?
What do we need to have consensus on before this PR is merged?
Why can we skip configure and make for the Systemtap dependecy? What are the problems and how are they solved?
Can you verify that the tracepoints are NOPs in the binaries? If yes, how?
<michaelfolkson> Not sure whether this should be fixed first "The tracepoints are currently not automatically/CI tested" before this is merged (but I think that is a later question on Approach ACK/NACK)
<b10c> next question: For GUIX builds, why do we need to add the Systemtap sys/std.h header as a dependency instead of using the header file avaliable on the GUIX build host system?
<svav> Re sys/std.h dependency, as you saying in a GUIX build, when you set it as a dependency, it will look for sys/std.h within the specific GUIX container?
<b10c> we try to compile a small (2 loc) program during configure. that program includes sys/sdt.h and a simple tracepoint (the DTRACE_PROBE(context, event))
<b10c> svav: yes. AFAIK DTrace is older and from Sun, Systemtap was developed specifically for Linux. There exists some interoperability between the too, but I haven't tested anything in this direction
<svav> I don't run a Bitcoin node yet, but I'm thinking about it ... Presumably for all this Pull Request testing, people set up separate test environments that don't affect your main node, so what sort of technology is necessary for test environments? Thanks.
<svav> So, can you run multiple bitcoind on the same computer if you set some as test environments, or do you need to use virtual environments for each bitcoind?
<b10c> I also think we should have a bit more confidence that the tracepoints aren't broken by automatically testing them in the CI (or similar). michaelfolkson mentioned this earlier
<b10c> michaelfolkson: yes, e.g. in the Python test suite. It's a bit tricky as you need special permissions to hook into the tracepoints, but I think it's doable. See https://github.com/bitcoin/bitcoin/issues/23296
<b10c> yes, it can. I sadly haven't found any documentation on that feature being added to gcc (all documentation I saw just lists it as 'this is supported')