This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: too many transport failure


Thanks for the help.

If I store the pp and address in the global array, will that cause a
lot of runtime overhead? Do I need to check whether the pp is saved in
the global array or not in every function tracing?

Do we have solutions like "stap -l", which prints out function name
and source code information, if it comes with function address, then
it looks perfect.

Zhiwei


On Fri, Apr 1, 2011 at 9:35 AM, Josh Stone <jistone@redhat.com> wrote:
> 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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]