This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: kernel summit session on systemtap
- From: "R. J. Moore" <rasman at uk dot ibm dot com>
- To: systemtap at sources dot redhat dot com
- Date: Thu, 18 Sep 2008 09:00:15 +0100
- Subject: Re: kernel summit session on systemtap
I don't know whether it is possible with the latest code, but for
debugging purposes, I would be happy if SystemTap could operate on
external names and relative addresses - i.e. without the need to have
any symbolic information. This is the way I used ancestors to systemtap
for shooting very difficult kernel problems in the field. Generally I
started with a crashdump. Determined that I needed some extra info in a
particular code path. Looked at the underlying assembler and plugged in
a probepoint at the required location as a relative address to the
beginning of the load module. I used this technique 100s and 100s of
times to shoot those bugs that would only show in live environment with
a complex work load patterns. I admit that this is extreme debugging,
but if system tap won't even operate without a ton of extra junk present
then I see its application as being very limited indeed. Not everyone
will want to work at the assembler level, but if System Tap can, then
tools can be built that do code analysis to help generate and divine
probepoints. Much can be done knowing that nearly 100% of the code we
probe is generated by the one tool - gcc. In theory, what is generated
is deterministic, or the reverse engineering of it is.
We should not ignore System Tap efficacy when being used to complement
core dumps, crash dumps, kernel and application debuggers.
Richard
--
Richard J Moore
Tel: (44) 1962-817072
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU