20:59 <irker037> systemtap: smakarov systemtap.git:master * release-4.4-117-gcd7b3e061 / tapset/bpf/uconversions.stp tapset/uconversions.stp testsuite/systemtap.bpf/bpf-target.c testsuite/systemtap.bpf/bpf_target_tests/user_long.stp: PR27030 bpf/uconversions.stp: other sizes user_*_error()

22:15 <kerneltoast> fche, soe

22:16 <fche> hi

22:16 <kerneltoast> lo

22:16 <kerneltoast> and behold

22:16 <kerneltoast> it is monday

22:34 <fche> I haven't forgotten about your bug - or should I say possible bug

22:34 <fche> am testing things here with symbol resolution with a non-php test case

22:34 <fche> sudo env DEBUGINFOD_URLS=$DEBUGINFOD_URLS stap -e 'probe process("/lib64/libc.so.6").function("signal") { if ($handler <= 1) next; println(execname(), " ", $handler, " ", usymdata($handler)) }' -d /bin/bash -d /bin/zsh -d /bin/stap -d /bin/gcc -d /bin/as -d /bin/awk --ldd -d /usr/libexec/gcc/x86_64-redhat-linux/10/cc1

22:35 <fche> note the usymdata() call

22:35 <fche> and while that is running, run any of those -d programs, so they run signal(3), and so this copy of stap must resolve the signal-handler function pointert

22:35 <fche> .....

22:35 <fche> and it looks like it's working fine for me for all these binaries

22:46 <fche> and on my version of php zif_usleep doesn't take a $target parameter