Once again, a lovely article by Chris Wellons. Fun to see him having idols :)
ps: the hammer story linked at the end is worth the minute reading http://archive.is/OV1kQ
Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
11–20 of 34 posts
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#12> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies. Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1]. See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/b…
The extra capabilities Linux added made it insecure (arrays), so that eBPF needs to be disabled in production SMP systems. There's also no existing userland support. Everyone provides DTrace probes, no one systemtap probes.
You can trace dtrace probes with ebpf.. see https://github.com/iovisor/bpftrace/blob/master/docs/referen...
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#13> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies. Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1]. See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/b…
The extra capabilities Linux added made it insecure (arrays), so that eBPF needs to be disabled in production SMP systems. There's also no existing userland support. Everyone provides DTrace probes, no one systemtap probes.
BPF is compatible with DTrace probes.
The kernel verifier does extensive bounds checks on array uses and jumps in BPF programs.
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#14> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies. Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1]. See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/b…
> * in the sense that it's even more capable* Examples? I don't see how it's more capable. Catching up with dtrace, maybe.
bpftrace's potential is higher than DTrace's, but at the moment it's definitely not reached parity. For example: we cannot yet read strings bigger than about 240 bytes (any bigger won't fit on the BPF stack).
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#15Earlier quoted context omitted.
The extra capabilities Linux added made it insecure (arrays), so that eBPF needs to be disabled in production SMP systems. There's also no existing userland support. Everyone provides DTrace probes, no one systemtap probes.
BPF is compatible with DTrace probes. The kernel verifier does extensive bounds checks on array uses and jumps in BPF programs.
Those checks don't save you from spectre-like cache exploitation. DTrace was designed with maps-only for a reason.
Thanksfully there's now Oracle Linux with DTrace-proper.
When the usdt syntax can use static DTrace probes, why isn't it documented then? and why doesn't it use the familiar DTrace syntax then? Why is nobody using it?
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#16> Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that I don't think the author understands with NIH means in practise, and this completely misplaces the blame. It's not as though the kernel team was completely unwilling to consider porting ZFS or DTrace, it's that for legal reasons they were unable.
No (unfortunately) it's NIH and nothing more. https://youtu.be/TgmA48fILq8?t=4266 https://marc.info/?l=linux-kernel&m=154714516832389&w=2
You've also missed what was said on the mailing list message. Sun specifically made a new license to make it legally impossible to include DTrace and ZFS (and other things) into a GPL licensed project.
That's a huge difference to what NIH means, which is that just because I didn't make it, I'm not going to use it, I'll make my own version instead.
They couldn't ever use the original version of things because they're legally bound to not do so. The kernel has had a long standing policy of not keeping APIs that either they or userspace aren't using to reduce their burden and the case of keeping that API just for ZFS since literally nothing else in the kernel was using it wasn't a good enough argument to keep it. ZFS on Linux has now worked around the removal of the API.
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#17Earlier quoted context omitted.
No (unfortunately) it's NIH and nothing more. https://youtu.be/TgmA48fILq8?t=4266 https://marc.info/?l=linux-kernel&m=154714516832389&w=2
You've also missed what was said on the mailing list message. Sun specifically made a new license to make it legally impossible to include DTrace and ZFS (and other things) into a GPL licensed project. That's a huge difference to what NIH means, which is that just because I didn't make it, I'm not going to use it, I'll make my own version instead. They couldn't ever use the original version of things because they're…
"ZFS on Linux has now worked around the removal of the API."
I'm just curious: how did they do that?
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#18I'm a big fan of dtrace and I use it daily. However, the system call tracing that the author did here could easily have been done without dtrace. Eg, via strace on the curl process (or truss, ktrace, or whatever your OSe's system call tracer is).
The author evidently didn't find that option attractive:
« To run curl under strace from Emacs, I’d have to modify Emacs’ behavior to do so. With DTrace I can instrument every curl process without making a single change to Emacs, and with negligible impact to Emacs. That’s a big deal. »
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#19Earlier quoted context omitted.
You've also missed what was said on the mailing list message. Sun specifically made a new license to make it legally impossible to include DTrace and ZFS (and other things) into a GPL licensed project. That's a huge difference to what NIH means, which is that just because I didn't make it, I'm not going to use it, I'll make my own version instead. They couldn't ever use the original version of things because they're…
"ZFS on Linux has now worked around the removal of the API." I'm just curious: how did they do that?
Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)
#20I'm a big fan of dtrace and I use it daily. However, the system call tracing that the author did here could easily have been done without dtrace. Eg, via strace on the curl process (or truss, ktrace, or whatever your OSe's system call tracer is).
The author evidently didn't find that option attractive: « To run curl under strace from Emacs, I’d have to modify Emacs’ behavior to do so. With DTrace I can instrument every curl process without making a single change to Emacs, and with negligible impact to Emacs. That’s a big deal. »
The usual trick to use strace in that kind of situation is to write a script named "curl" that runs curl under strace, and stick the script in your path.
If the author is familiar with DTrace, though, sounds like that's a great solution for them.