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 everyone for the help. I did some experiment to test uaddr()
and REG_IP. uaddr is not useful, while REG_IP is ok but not perfect to
match pp()

First I tested with uaddr, the return value of uaddr cannot match
pp(). Some different functions have same uaddr.
USER,      0 read_chardev(19657): 8048487
process("/ddtv/read_chardev").function("main@../../../test/script/read_chardev.c:13").call
argc=0x1 argv=0xbfa008a4
USER,      0 read_chardev(19657):  8048474
process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
funcName=0x8048604
USER      0 read_chardev(19657):  80484bb user_trace
DRVR      0 read_chardev(19657):  8ae416
module("chardev").function("device_open@/ddtv/chardev.c:144").call
DRVR      0 read_chardev(19657):   8ae416
module("chardev").function("trace_kmalloc@include/trace/events/kmem.h:87").call
DRVR      0 read_chardev(19657):   8ae416 trace_kmalloc
DRVR      0 read_chardev(19657):   8ae416
module("chardev").function("kern_alloc@/ddtv/chardev.c:73").call
DRVR      0 read_chardev(19657):   8ae416 kern_alloc
DRVR      0 read_chardev(19657):   8ae416
module("chardev").function("kern_alloc1@/ddtv/chardev.c:79").call
DRVR      0 read_chardev(19657):   8ae416 kern_alloc1
DRVR      0 read_chardev(19657):   8ae416
module("chardev").function("trace_kmalloc@include/trace/events/kmem.h:87").call
DRVR      0 read_chardev(19657):   8ae416 trace_kmalloc
DRVR      0 read_chardev(19657):  8ae416 device_open
DRVR      0 read_chardev(19657):  8ae416
module("chardev").function("device_read@/ddtv/chardev.c:205").call
DRVR      0 read_chardev(19657):  8ae416 device_read
USER,      0 read_chardev(19657):  8048474
process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
funcName=0xbfa00768
USER      0 read_chardev(19657):  804851e user_trace
USER,      0 read_chardev(19657):  8048474
process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
funcName=0x8048632
USER      0 read_chardev(19657):  804852a user_trace
DRVR      0 read_chardev(19657):  8ae416
module("chardev").function("device_release@/ddtv/chardev.c:188").call
DRVR      0 read_chardev(19657):  8ae416 device_release
USER      0 read_chardev(19657): 60acc6 main return=0x0
start dumping
ip=8048487 pp=process("/ddtv/tread_chardev").function("main@../../../test/script/read_chardev.c:13").call
ip=8048474 pp=process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
ip=80484bb pp=process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").return
ip=8ae416 pp=module("chardev").function("device_open@/ddtv/chardev.c:144").call
ip=804851e pp=process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").return
ip=804852a pp=process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").return
ip=60acc6 pp=process("/ddtv/read_chardev").function("main@../../../test/script/read_chardev.c:13").return
end of tracing


Then I tried with REG_IP, different function has different REG_IP
value. What's this IP? The IP of instrumentation function or the
function being instrumented? I got two REG_IP value for the return
function of user_trace. If one function's REG_IP is not unique, I have
concern on the size the hash table.

USER,      0 read_chardev(20705): 8048487
process("/ddtv/read_chardev").function("main@../../../test/script/read_chardev.c:13").call
argc=0x1 argv=0xbfca5084
USER,      0 read_chardev(20705):  8048474
process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
funcName=0x8048604
USER      0 read_chardev(20705):  80484bb user_trace
DRVR      0 read_chardev(20705):  f840621f
module("chardev").function("device_open@/ddtv/chardev.c:144").call
DRVR      0 read_chardev(20705):   f84061aa
module("chardev").function("trace_kmalloc@include/trace/events/kmem.h:87").call
DRVR      0 read_chardev(20705):   f8406292 trace_kmalloc
DRVR      0 read_chardev(20705):   f84061f5
module("chardev").function("kern_alloc@/ddtv/chardev.c:73").call
DRVR      0 read_chardev(20705):   f84062a9 kern_alloc
DRVR      0 read_chardev(20705):   f840620b
module("chardev").function("kern_alloc1@/ddtv/chardev.c:79").call
DRVR      0 read_chardev(20705):   f84062b3 kern_alloc1
DRVR      0 read_chardev(20705):   f84061aa
module("chardev").function("trace_kmalloc@include/trace/events/kmem.h:87").call
DRVR      0 read_chardev(20705):   f84062e9 trace_kmalloc
DRVR      0 read_chardev(20705):  c04d40a0 device_open
DRVR      0 read_chardev(20705):  f8406090
module("chardev").function("device_read@/ddtv//chardev.c:205").call
DRVR      0 read_chardev(20705):  c04d1d98 device_read
USER,      0 read_chardev(20705):  8048474
process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
funcName=0xbfca4f48
USER      0 read_chardev(20705):  804851e user_trace
USER,      0 read_chardev(20705):  8048474
process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
funcName=0x8048632
USER      0 read_chardev(20705):  804852a user_trace
DRVR      0 read_chardev(20705):  f8406074
module("chardev").function("device_release@/ddtv/chardev.c:188").call
DRVR      0 read_chardev(20705):  c04d292f device_release
USER      0 read_chardev(20705): 60acc6 main return=0x0
start dumping
ip=8048487 pp=process("/ddtv/read_chardev").function("main@../../../test/script/read_chardev.c:13").call
ip=8048474 pp=process("/ddtv/read_chardev").function("user_trace@../../../test/script/read_chardev.c:8").call
ip=80484bb pp=user_trace
ip=f840621f pp=module("chardev").function("device_open@/ddtv/chardev.c:144").call
ip=f84061aa pp=module("chardev").function("trace_kmalloc@include/trace/events/kmem.h:87").call
ip=f8406292 pp=trace_kmalloc
ip=f84061f5 pp=module("chardev").function("kern_alloc@/ddtv/chardev.c:73").call
ip=f84062a9 pp=kern_alloc
ip=f840620b pp=module("chardev").function("kern_alloc1@/ddtv/chardev.c:79").call
ip=f84062b3 pp=kern_alloc1
ip=f84062e9 pp=trace_kmalloc
ip=c04d40a0 pp=device_open
ip=f8406090 pp=module("chardev").function("device_read@/ddtv/chardev.c:205").call
ip=c04d1d98 pp=device_read
ip=804851e pp=user_trace
ip=804852a pp=user_trace
ip=f8406074 pp=module("chardev").function("device_release@/ddtv/chardev.c:188").call
ip=c04d292f pp=device_release
ip=60acc6 pp=main
end of tracing



On Sat, Apr 2, 2011 at 4:07 AM, Josh Stone <jistone@redhat.com> wrote:
> On 04/01/2011 12:48 PM, Frank Ch. Eigler wrote:
>>
>> jistone wrote:
>>
>>> [...]
>>>> pp() will print a long string, thought that consumes a lot of buffer.
>>>> [...]
>>> 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;
>>> ? %}
>>
>> That's weird, we have uaddr() already. ?There should be a raw
>> version of it with that content, named something better.
>
> Yeah, I was surprised too. ?I have to wonder if we had some reason for
> that omission, but I didn't find any such documentation...
>
>>> Then, we don't have any automatic way to associate that to a pp() [...]
>>
>> What about symname(REG_IP())?
>
> Sure, this should give the same info as probefunc() would directly in
> the probe, though symname can be delayed. ?So long as you don't care
> about the rest of pp(), like source location, then you could print each
> IP at probe time and symname(ip) later to decode them.
>


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