On Mon, May 16, 2022 at 04:31:55PM -0700, Andrii Nakryiko wrote: > On Thu, May 12, 2022 at 12:43 AM Dave Marchevsky <davemarchevsky@xxxxxx> wrote: > > > > Validate that bpf_get_reg_val helper solves the motivating problem of > > this patch series: USDT args passed through xmm regs. The userspace > > portion of the test forces STAP_PROBE macro to use %xmm0 and %xmm1 regs > > to pass a float and an int, which the bpf-side successfully reads using > > BPF_USDT. > > > > In the wild I discovered a sanely-configured USDT in Fedora libpthread > > using xmm regs to pass scalar values, likely due to register pressure. > > urandom_read_lib_xmm mimics this by using -ffixed-$REG flag to mark > > r11-r14 unusable and passing many USDT args. > > > > Signed-off-by: Dave Marchevsky <davemarchevsky@xxxxxx> > > --- > > tools/testing/selftests/bpf/Makefile | 8 ++- > > tools/testing/selftests/bpf/prog_tests/usdt.c | 7 +++ > > .../selftests/bpf/progs/test_urandom_usdt.c | 13 ++++ > > tools/testing/selftests/bpf/urandom_read.c | 3 + > > .../selftests/bpf/urandom_read_lib_xmm.c | 62 +++++++++++++++++++ > > 5 files changed, 91 insertions(+), 2 deletions(-) > > create mode 100644 tools/testing/selftests/bpf/urandom_read_lib_xmm.c > > > > diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile > > index 6bbc03161544..19246e34dfe1 100644 > > --- a/tools/testing/selftests/bpf/Makefile > > +++ b/tools/testing/selftests/bpf/Makefile > > @@ -172,10 +172,14 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c > > $(call msg,LIB,,$@) > > $(Q)$(CC) $(CFLAGS) -fPIC $(LDFLAGS) $^ $(LDLIBS) --shared -o $@ > > > > -$(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so > > +$(OUTPUT)/liburandom_read_xmm.so: urandom_read_lib_xmm.c > > + $(call msg,LIB,,$@) > > + $(Q)$(CC) -O0 -ffixed-r11 -ffixed-r12 -ffixed-r13 -ffixed-r14 -fPIC $(LDFLAGS) $^ $(LDLIBS) --shared -o $@ > > this looks very x86-specific, but we support other architectures as well > > looking at sdt.h, it seems like STAP_PROBEx() macros support being > called from assembly code, I wonder if it would be better to try to > figure out how to use it from assembly and use some xmm register > directly in inline assembly? I have never done that before, but am > hopeful :) stap_probe in asm won't help cross arch issue. It's better to stay with C. Maybe some makefile magic can make the above x86 only? The test should be skipped on other archs anyway.
