Re: [RFC] elfutils: Checks for debuginfo file without .debug extension as well

[Ravi Bangoria <ravi dot bangoria at linux dot vnet dot ibm dot com>]

HI Mark,

Thanks for giving detailed analysis. Please find my comments.

On Wednesday 17 February 2016 09:19 PM, Mark Wielaard wrote:
> Hi Ravi,
>
> My apologies for being slightly confused. I think what you are proposing
> with your patch is the right thing. I am just slightly confused because
> I thought the current code already did what you are proposing. So the
> current code doesn't actually do what I thought it did :)
>
> I have attached a simplified version of what I believe systemtap is
> doing. It is a two step process. First it calls
> dwfl_linux_kernel_report_offline to get the kernel file itself. Second
> it gets the Dwarf for the kernel module, which should trigger
> find_debuginfo to find the separate debug file, if needed.

Thanks for the sample program. I can see it tries to simulate what 
systemtap do.
Here is the output on ubunut powerpc.

Without patch:

  # ./dwfl_find_kernel
  Finding kernel release: 3.13.0-76-generic
  Debuginfo path: +:.debug:/usr/lib/debug
  setup report modname: kernel, filename: /boot/vmlinux-3.13.0-76-generic
  setup report modname: xfrm_user, filename: 
/lib/modules/3.13.0-76-generic/kernel/net/xfrm/xfrm_user.ko
  Found kernel file: /boot/vmlinux-3.13.0-76-generic
  getdwarf name: kernel
  kernel without DWARF
  Couldn't get kernel DWARF


With patch:

  # ./dwfl_find_kernel
  Finding kernel release: 3.13.0-76-generic
  Debuginfo path: +:.debug:/usr/lib/debug
  setup report modname: kernel, filename: /boot/vmlinux-3.13.0-76-generic
  setup report modname: xfrm_user, filename: 
/lib/modules/3.13.0-76-generic/kernel/net/xfrm/xfrm_user.ko
  Found kernel file: /boot/vmlinux-3.13.0-76-generic
  getdwarf name: kernel
  mainfile: /boot/vmlinux-3.13.0-76-generic, debugfile: 
/usr/lib/debug/boot/vmlinux-3.13.0-76-generic
  Found kernel DWARF file: /usr/lib/debug/boot/vmlinux-3.13.0-76-generic


> It still doesn't show the full search path (for that we should hack
> find_debuginfo_in_path and try_open in libdwfl/find-debuginfo.c a bit),
> but it should be a start to better understand why the current search
> isn't finding the separate kernel debug file.

Sry, I'm little bit confused in your last two paragraphs.

1. Does this means change I've proposed is at wrong place i.e. 
find_debuginfo
is not correct place to change?

2. I'm not able to understand why kernel module came into picture here. 
when we do
        probe kernel.function("do_fork") {...}
stap looks for kernel debuginfo only, right?

Regards,
Ravi