Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Jun 2018 19:43:03 -0400
From:      Ash Gokhale <ashfixit@gmail.com>
To:        Ryan Stone <rysto32@gmail.com>
Cc:        Dave Cottlehuber <dch@skunkwerks.at>, freebsd-dtrace@freebsd.org
Subject:   Re: where did FreeBSD 11's syscall::lstat go? where do syscall probes get defined?
Message-ID:  <CAHpe%2B0bBPgeTsumBaaf%2B4PCLhvNd4K6ycbJQgcoTsRdkNVnn6g@mail.gmail.com>
In-Reply-To: <CAFMmRNxn7=k3DwictuDJ5oDt9Wn6DDA2CMamw63wDb0%2Bpmyvaw@mail.gmail.com>
References:  <1529348905.2613088.1412091424.2D14994E@webmail.messagingengine.com> <CAFMmRNxn7=k3DwictuDJ5oDt9Wn6DDA2CMamw63wDb0%2Bpmyvaw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 18, 2018 at 3:15 PM, Ryan Stone <rysto32@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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace
> To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHpe%2B0bBPgeTsumBaaf%2B4PCLhvNd4K6ycbJQgcoTsRdkNVnn6g>