Re: too many transport failure

[Adrien Kunysz <adrien at kunysz dot be>]

You can match symbols addresses to names by looking at /proc/kallsyms
or using the lookup_symbol_name() kernel function. Both require the
kernel to be compiled with the CONFIG_KALLSYMS option I think.

On Fri, Apr 01, 2011 at 05:10:50PM +0800, Zhiwei Ying wrote:
> 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
> >

Attachment: signature.asc
Description: Digital signature