On Mon, Jun 18, 2018 at 3:15 PM, Ryan Stone <[email protected]> wrote:
> The syscall probes are automatically defined based off of the > syscalls.master file. As a part of ino64, it seems that lstat() was > retired as a system call. As you can see in lstat.c, lstat(3) is now > implemented in terms of fstatat(2), so that's what new scripts should > be used. > > You can also see that syscalls.master defines a compat11 version of > lstat(), as this is necessary to maintain binary compatibility with > pre-12.0 binaries. > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "[email protected]" > Looks like lstat probe can hit as part of libc, pid provider, But unfortunately now you need to pretarget a process . #dtrace -p `pgrep foo` -ln 'pid$target::lstat*:entry { }' ID PROVIDER MODULE FUNCTION NAME 57364 pid33074 libc.so.7 lstat entry To understand the rework; grab all the syscalls and look for patterns that explain the program behaviour. syscall:::entry /execname =="wahtever"/ { @[probefunc]=count () ;}' This is an example of the principle that dtrace scripts are bespoke; writing them to be portable is not generally easy. The notion of probe stability classes attempts to answer for the need for durable interfaces, but automatically generated probes are going to fool us. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace To unsubscribe, send any mail to "[email protected]"
