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: 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:

	[2305e7]      formal_parameter
		       name                 "prev"
		       decl_file            1
		       decl_line            1754
		       type                 [21eb3f]
		       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.


Thanks,
Roland


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