sysutils/DTraceToolkit: remove missing providers in FreeBSD 12.0-CURRRENT

[dch]

Summary

dtruss fails as syscall::lstat*:return is no longer present.

This may well be a problem in FreeBSD src that needs addressing, but
might as well start with a working port for the moment.

dtruss is a super handy sysadmin-level trace tool that would be a shame
to lose.

[markj]

I'll admit that I've never seen any reason to prefer dtruss to truss(1).

[mat]

Mmmm, there is no such thing as 12.0, yet. And when it comes out, it will definitively not have 1200000 as a version.

I think it would be better if you could track which OSVERSION bump is after the removal of those providers and use it instead.

[dch]

In D15879#335907, @mat wrote:

Mmmm, there is no such thing as 12.0, yet. And when it comes out, it will definitively not have 1200000 as a version.
I think it would be better if you could track which OSVERSION bump is after the removal of those providers and use it instead.

Yes; I have no way of working that out other than wastefully building kernel/world/ports & re-trying it. IIRC, it broke just
before BSDCan 2017, looking through https://www.freebsd.org/doc/en/books/porters-handbook/versions.html this is most likely:

1200031 318736 May 23, 2017 12.0-CURRENT after types ino_t, dev_t, nlink_t were extended to 64bit and struct dirent changed layout (also known as ino64).

https://svnweb.freebsd.org/base?view=revision&revision=318736 where lib/libc/sys/stat.c & lib/libc/sys/lstat.c were added.

For my reference, from 11.2-RC3. The last 2 are missing on 12.0-CURRENT.

dtrace -l syscall  |rg '\b[l ]stat'
67307        tcp            kernel                              none state-change
68948    syscall           freebsd                      compat.lstat entry
68949    syscall           freebsd                      compat.lstat return
69248    syscall           freebsd                             lstat entry
69249    syscall           freebsd                             lstat return

Options to move forward:

• use 1200000 as the bracket and accept we're also excluding a period where this did work
• use 1200031 and probably get pretty close but not be certain
• hope Mark or Devin shares some insight on where/how providers are created for syscalls[1]
• rebuild 12.0+ports at that point last year and bisect furiously

FWIW I also found that syscall::*lstat*:return works everywhere, so that is probably
the easiest option, but I'd still like to understand how dtrace providers are generated
for syscalls.

[dteske]

In D15879#336047, @dch wrote:

Options to move forward:

• use 1200000 as the bracket and accept we're also excluding a period where this did work
• use 1200031 and probably get pretty close but not be certain
• hope Mark or Devin shares some insight on where/how providers are created for syscalls[1]
• rebuild 12.0+ports at that point last year and bisect furiously

FWIW I also found that syscall::*lstat*:return works everywhere, so that is probably
the easiest option, but I'd still like to understand how dtrace providers are generated
for syscalls.

The magic happens in sys/cddl/dev/systrace/systrace.c

That relies on the similarly magical sys/kern/makesyscalls.sh

makesyscalls.sh reads sys/sys/syscall.h which we can see has changed with respect to lstat.

What was once SYS_lstat is now SYS_freebsd11_lstat.

If we do view annotated version of the file:

https://svnweb.freebsd.org/base/head/sys/sys/syscall.h?view=annotate

We can readily see that the change to introduce SYS_freebsd11_lstat was done May 23, 2017:

https://svnweb.freebsd.org/base?view=revision&revision=318737

Now, we can work that back by setting a sticky bit in SVNweb to find out what the appropriate __FreeBSD_version value from sys/sys/param.h would be for the port Makefile:

https://svnweb.freebsd.org/base/head/sys/sys/param.h?view=log&pathrev=318737

So there you have it. As @dch suggests, the value of 1200031 was just prior 97 seconds before the change in syscalls, so I would say that is a really good anchor to choose. The next option, 1200032, is not a good choice as it is over 2 weeks later.

[dch]

• use wildcard to pick up compat* entries rather than ignore them
• use more specific OSVERSION to match up point of breakage

[mat]

sysutils/DTraceToolkit/Makefile

91–94 ↗

(On Diff #44777)

Are you sure about the -s flag here? I am of what install does when asked to symlink, and to strip at the same time.

sysutils/DTraceToolkit/files/extra-patch-dtruss

7–8 ↗

(On Diff #44777)

Unless I am mistaken, *lstat* would also match lstat*, in which case, the patch could always be applied.

[dch]

sysutils/DTraceToolkit/files/extra-patch-dtruss

7–8 ↗

(On Diff #44777)

This did cross my mind, however this would also change the working behaviour for < 1200031 by including a number of other syscalls. This seems a reasonable compromise.

[mat]

sysutils/DTraceToolkit/Makefile

91–94 ↗

(On Diff #44777)

ping for this.

[dch]

fix last nit for {$RLN}

• add manpage for dtruss(1)
• add dtruss(1) to /usr/local/bin

[dch]

sysutils/DTraceToolkit/Makefile

91–94 ↗

(On Diff #44777)

I suspect the port was previously updated from ln -s to {$RLN} and this was never removed.

[jrm]

[dch]

ping @dteske are you ok for this to land? thanks!

[dteske]

sysutils/DTraceToolkit/Makefile

97 ↗

(On Diff #45202)

Can you move dtruss to before hotkernel so that the order of entries on this line matches the order of RLN entries above (retaining pre-patch status)

[dch]

polish MANPAGE order

[jrm]