This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] elfutils: Checks for debuginfo file without .debug extension as well
- From: Ravi Bangoria <ravi dot bangoria at linux dot vnet dot ibm dot com>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: elfutils-devel at lists dot fedorahosted dot org, systemtap at sourceware dot org, naveen dot n dot rao at linux dot vnet dot ibm dot com, hemant at linux dot vnet dot ibm dot com, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Date: Fri, 19 Feb 2016 15:07:09 +0530
- Subject: Re: [RFC] elfutils: Checks for debuginfo file without .debug extension as well
- Authentication-results: sourceware.org; auth=none
- References: <1455639695-8350-1-git-send-email-ravi dot bangoria at linux dot vnet dot ibm dot com> <1455641106 dot 9915 dot 55 dot camel at redhat dot com> <56C42D5B dot 4020704 at linux dot vnet dot ibm dot com> <1455724164 dot 9915 dot 75 dot camel at redhat 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