2009-04-13 18:17:53     Analyzing kernel code using hardware trace

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.