Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018) • Hacker News Board

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#31

Post by grumpydba » Mon, Feb 04, 2019, 10:52 AM UTC

lelf wrote: post #8

ink_13 wrote: post #5

> 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

Linux guys did not invent xfs or jfs, yet they happily merged it. No NIH here. It is pretty silly to talk about that. If zfs license was compatible, they would have done the same.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#32

Post by ithkuil » Mon, Feb 04, 2019, 8:25 PM UTC

__david__ wrote: post #21

greglindahl wrote: post #20

Earlier quoted context omitted.

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.

I don't see why "strace -f" wouldn't suffice. I use that all the time for exactly these kinds of things.

Perhaps because you don't want to strace the whole emacs just to hit the curl process that gets forked off emacs.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#33

Post by dan-robertson » Tue, Feb 05, 2019, 12:03 PM UTC

rurban wrote: post #15

Birch-san wrote: post #13

Earlier quoted context omitted.

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?

> DTrace was designed with maps-only for a reason.

You write this like you are implying that the DTrace designers somehow foresaw that spectre would be a thing and therefore array accesses would be a risk. This is obviously false. I’m sure there are reasonable reasons to not have arrays but predicting spectre 10 years before it was found is not one of them.

Re: Debugging Emacs, or How I Learned to Stop Worrying and Love DTrace (2018)

#34

Post by rurban » Tue, Feb 05, 2019, 9:47 PM UTC

dan-robertson wrote: post #33

rurban wrote: post #15

Earlier quoted context omitted.

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?

> DTrace was designed with maps-only for a reason. You write this like you are implying that the DTrace designers somehow foresaw that spectre would be a thing and therefore array accesses would be a risk. This is obviously false. I’m sure there are reasonable reasons to not have arrays but predicting spectre 10 years before it was found is not one of them.

Ask Brian, he did it on purpose.