On Mon, May 16, 2022 at 6:17 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > 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. It seems easier (or rather cleaner) to maintain arch-specific pieces within .c file through #if __x86_64__ instead of doing equivalent changes to Makefile. Suggestion for using assembly was due to needing to make sure xmmX register is used and desired to avoid maintaining arch-specific compile-time flags like -ffixed-r11. But truth be told I have zero idea how STAP_PROBE() use from assembly would look like, so just a suggestion to consider.
