Re:Linux perf rides the rocket
by toothrot on Friday September 12, 2014 @11:39AM
(#8308606)
"Rides the Rocket" is a reference to Quake. It's a pretty crude joke about getting shot by a rocket launcher in the classic Quake deathmatch. It's likely there because of the similar, "frags", which is what they called kills, gruesomely short for the same "fragmentation"
Re:Linux perf rides the rocket
by derefr on Thursday September 11, 2014 @11:48PM
(#8306512)
I see these most often on a EC2 PV instance's console when I'm watching it during instance termination. Apparently the (Ubuntu 14.04) kernel does something the xennet driver really doesn't like while shutting down.
Re:Linux perf rides the rocket
by brendangregg on Thursday September 11, 2014 @11:38PM
(#8306488)
Depends how similar. This article was specifically about kernel line number and local variable tracing, which I've only seen Linux do.
If you mean general kernel debugging, then my book on DTrace covers multiple operating systems including FreeBSD, and has around a thousand pages of examples.
It would be nice if DTrace could add kernel line number and local variable tracing. Recently I've seen FreeBSD kernel builds where inlining has become more common than I've seen in the past, and missing kernel functions is becoming a bit of a nuisance. It's generally possible to work around it, but it would be nice to just trace lines and variables if needed.
Relevant upstream discussion: http://www.spinics.net/lists/netdev/msg282340.html
If you mean general kernel debugging, then my book on DTrace covers multiple operating systems including FreeBSD, and has around a thousand pages of examples.
It would be nice if DTrace could add kernel line number and local variable tracing. Recently I've seen FreeBSD kernel builds where inlining has become more common than I've seen in the past, and missing kernel functions is becoming a bit of a nuisance. It's generally possible to work around it, but it would be nice to just trace lines and variables if needed.
That looks like it just came from debugging info. I.e. the numbered lines correspond to places where a debugger could put a breakpoint.