This is the mail archive of the
mailing list for the systemtap project.
Re: loc2-test and stap disagree with each other
- From: Roland McGrath <roland at redhat dot com>
- To: Hien Nguyen <hien at us dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Tue, 11 Jul 2006 20:28:54 -0700 (PDT)
- Subject: Re: loc2-test and stap disagree with each other
Uh. Well, ok, I said "we", but what I meant is that *you* should look at
the assembly code, not just find a ton of assembly code to email me.
Look at the disassembly for the code where the probe went (objdump -SD can
be good for this, or using gdb's disassembler is often handy). Figure out
where the variable "prev" is located from what the assembly is actually doing.
Then we can see what the answer should have been.
Next, find the DWARF DIE offset for the variable.
That's the number in [...] in the output of "loc2c-test -k 0x...".
>From your earlier mail:
prev [43c0e6] task_t*
Use eu-readelf --debug-dump=info (and DO NOT MAIL ME THE WHOLE THING!),
and search for 43c0e6 to find the details of its DIE. In a different
kernel where the offsets are different, that block looks like this:
location location list [ 2bb92]
Take the offset given for "location", corresponding to 2bb92 here.
Then use eu-readelf --debug-dump=loc and search for that offset.
That gets you the location list for this variable, which will look
something like this:
[ 2bb92] 0xc011b8d9..0xc011b94c [ 0] fbreg 0
0xc011b94c..0xc011b9ae [ 0] breg5 8
This list ends before the next line of the output that has a "[ nnnnn]" at
the beginning. Post here just that location list info, and the assembly
code for the "schedule" function, but not any more assembly code than that.