too many transport failure

[Adrien Kunysz]

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
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/systemtap/attachments/20110401/3dc6003f/attachment.sig>