2009-04-13 18:17:53 Analyzing kernel code using hardware trace
Jeff Tan (UNITED STATES)
Message: 72612
Hi,
When our firmware crashes, uclinux produces the following hardware trace output (only the part showing kernel-space code):
Source : <0xffa081ea> { __common_int_entry + 0xd8 }
11 Target : <0xffa08188> { __common_int_entry + 0x76 }
Source : <0xffa08428> { _evt_system_call + 0x64 }
12 Target : <0xffa08428> { _evt_system_call + 0x64 }
Source : <0x00007f60> { _system_call + 0xb8 }
13 Target : <0x00007f5c> { _system_call + 0xb4 }
Source : <0x00007f4c> { _system_call + 0xa4 }
14 Target : <0x00007f46> { _system_call + 0x9e }
Source : <0x00007f36> { _system_call + 0x8e }
15 Target : <0x00007f10> { _system_call + 0x68 }
Source : <0x00004092> { _sys_bfin_spinlock + 0x1e }
How do I find out where in the kernel source (file names + line numbers) these addresses correspond to?
Any help will be appreciated. Thanks.
Jeff
QuoteReplyEditDelete
2009-04-13 18:24:41 Re: Analyzing kernel code using hardware trace
Mike Frysinger (UNITED STATES)
Message: 72613
you have to look up the source yourself (meaning there is no real shortcut method). that means either using grep, or a package like ctags, or you can try the online system:
lxr.linux.no/
QuoteReplyEditDelete
2009-04-13 19:15:47 Re: Analyzing kernel code using hardware trace
Jeff Tan (UNITED STATES)
Message: 72614
Hi Mike,
Thanks for the reply.
So do you mean that if I want to find out where "Source : <0xffa081ea> { __common_int_entry + 0xd8 }" is in the kernel source, I have to search "common_int_entry" in the whole kernel source tree?
Jeff
QuoteReplyEditDelete
2009-04-13 19:34:14 Re: Analyzing kernel code using hardware trace
Mike Frysinger (UNITED STATES)
Message: 72615
the Linux kernel is just like any other ELF application. so any method you'd use to find a function in an application is exactly the same way as the kernel. that means searching the entire source tree or using addr2line or ...
QuoteReplyEditDelete
2009-04-13 19:53:13 Re: Analyzing kernel code using hardware trace
Jeff Tan (UNITED STATES)
Message: 72616
OK, I guess that I did not state my question appropriately. So in the particular case of "Source : <0xffa081ea> { __common_int_entry + 0xd8 }", I am not sure what address I should pass to the bfin-uclinux-addr2line command. 0xffa081ea is obviously the absolution address and 0xd8 is a relative address counting from the symbol __common_int_entry. But where is __common_int_entry?
Thanks.
QuoteReplyEditDelete
2009-04-13 19:56:13 Re: Analyzing kernel code using hardware trace
Mike Frysinger (UNITED STATES)
Message: 72617
addr2line can take any address. it does not need to be function entry points.
as for your question, it looks like pretty straight forward algebra / subtraction to me.
0xffa081ea = __common_int_entry + 0xd8
0xffa081ea - 0xd8 = __common_int_entry
__common_int_entry = 0xffa081ea - 0xd8
__common_int_entry = 0xffa08112
QuoteReplyEditDelete
2009-04-13 20:46:05 Re: Analyzing kernel code using hardware trace
Jeff Tan (UNITED STATES)
Message: 72618
So the address reported in the hardware trace is actually the offset in the executable file rather than the address of the memory where the code executes? I thought it was the latter and wondered how to do a memory address to file offset mapping.
Anyway, when I executed the command "bfin-uclinux-addr2line -f -e linux-2.6.x/vmlinux 0x00004092", I got:
_sys_bfin_spinlock
??:0
What does the second line (??:0) mean? Thanks.
QuoteReplyEditDelete
2009-04-13 21:04:39 Re: Analyzing kernel code using hardware trace
Mike Frysinger (UNITED STATES)
Message: 72619
the symbol/file/whatever reported is the best name we could find. if it says "libc.so.0 + 0x10", obviously it doesnt mean the file offset of "libc.so.0", it's talking about the executable mapping.
the kernel is not relocatable. so the addresses in the kernel ELF image are always exactly the same as when run on the target hardware.
if it says "??" it means it couldnt find the file. make sure you have debugging turned on. if it still cant find it, resort to the previous methods mentioned.