where did FreeBSD 11's syscall::lstat go? where do syscall probes get defined?

[Ash Gokhale]

On Mon, Jun 18, 2018 at 3:15 PM, Ryan Stone <rysto32 at gmail.com> 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.
> _______________________________________________
> freebsd-dtrace at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace
> To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe at freebsd.org"
>

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.