Re: git: ddf0ed09bd8f - main - sdt: Implement SDT probes using hot-patching

On Mon, Jun 24, 2024 at 08:36:55AM -0700, Ryan Libby wrote:
> On Wed, Jun 19, 2024 at 1:58 PM Mark Johnston <markj@freebsd.org> wrote:
> >
> > The branch main has been updated by markj:
> >
> > URL: https://cgit.FreeBSD.org/src/commit/?id=ddf0ed09bd8f83677407db36828aca2c10f419c9
> >
> > commit ddf0ed09bd8f83677407db36828aca2c10f419c9
> > Author:     Mark Johnston <markj@FreeBSD.org>
> > AuthorDate: 2024-06-19 20:57:09 +0000
> > Commit:     Mark Johnston <markj@FreeBSD.org>
> > CommitDate: 2024-06-19 20:57:41 +0000
> >
> >     sdt: Implement SDT probes using hot-patching
> >
> >     The idea here is to avoid a memory access and conditional branch per
> >     probe site.  Instead, the probe is represented by an "unreachable"
> >     unconditional function call.  asm goto is used to store the address of
> >     the probe site (represented by a no-op sled) and the address of the
> >     function call into a tracepoint record.  Each SDT probe carries a list
> >     of tracepoints.
> 
> Questions out of curiosity and maybe ignorance:
> 
> How does this work with relocations?  Something must be adjusting these
> addresses?

The compiler handles this as part of the implementation of asm goto:
the inline assembly can reference jump targets with "%l<index>" and
they're specified as operands to the asm goto statement.  In the kernel
these references are resolved statically, and kernel modules will
contain relocations for the sdt_tracepoint_set section.

> > +/*
> > + * Work around an apparent clang bug or limitation which prevents the use of the
> > + * "i" (immediate) constraint with the probe structure.
> > + */
> > +#define        _SDT_ASM_PROBE_CONSTRAINT       "Ws"
> > +#define        _SDT_ASM_PROBE_OPERAND          "p"
> 
> Is it because i386 kmods are built with -fPIC?

I suspect that that's related, yeah.  The compiler might be assuming
that some indirection is needed to compute the target address, but in
this case it's an address in the same function and presumably can safely
be assumed to be an immediate.

> By the way, it seems gcc13 (latest in ports) doesn't support the "Ws"
> constraint.  It seems to have been added to gcc 14.  I know i386 is tier
> 2 these days, and gcc is a second consideration anyway.  Trying to test
> out a patch for i386 gcc, I found that it doesn't build currently and
> this is one of a few reasons.

What happens if "i" is used with gcc?  IIRC I had tried gcc+i386 when
testing the patch but the kernel failed to build for other reasons at
the time.