From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: [RFC] elfutils: Checks for debuginfo file without .debug extension as well
Date: Fri, 19 Feb 2016 15:07:09 +0530 [thread overview]
Message-ID: <56C6E245.7020801@linux.vnet.ibm.com> (raw)
In-Reply-To: 1455724164.9915.75.camel@redhat.com
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]
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
next reply other threads:[~2016-02-19 9:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 9:37 Ravi Bangoria [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-02-22 19:54 Mark Wielaard
2016-02-22 17:12 Ravi Bangoria
2016-02-22 13:45 Mark Wielaard
2016-02-20 13:40 Ravi Bangoria
2016-02-19 15:11 Mark Wielaard
2016-02-17 15:49 Mark Wielaard
2016-02-17 8:20 Ravi Bangoria
2016-02-16 16:45 Mark Wielaard
2016-02-16 16:21 Ravi Bangoria
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56C6E245.7020801@linux.vnet.ibm.com \
--to=ravi.bangoria@linux.vnet.ibm.com \
--cc=elfutils-devel@lists.fedorahosted.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).