This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: too many transport failure
- From: Josh Stone <jistone at redhat dot com>
- To: Zhiwei Ying <zhiwei dot ying at gmail dot com>
- Cc: systemtap <systemtap at sources dot redhat dot com>
- Date: Thu, 31 Mar 2011 18:35:00 -0700
- Subject: Re: too many transport failure
- References: <AANLkTikdJ3+uTz2dnKJobmd9Z_moHbRg3LDWTm1sx=LA@mail.gmail.com>
On 03/31/2011 05:40 PM, Zhiwei Ying wrote:
> pp() will print a long string, thought that consumes a lot of buffer.
> Does systemtap has a ppid(), only print the function address? And
> provide a map between ppid() and pp() offline, so I can restore the
> pp() information offline.
Beware, there actually is a ppid(), but it means "parent process ID".
Do you really need the complete source information that pp() gives? It
would save a lot of bandwidth to use probefunc() in the .call probes,
just as you have in the .return probes.
You could get the raw probe address with a function like this:
function REG_IP:long() %{
THIS->__retvalue = CONTEXT->regs ? REG_IP(CONTEXT->regs) : 0;
%}
Then, we don't have any automatic way to associate that to a pp(), but
you could manually save that in a global array and print them all in an
end probe as a translation key for some post-processing script.
Josh