public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
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: Sat, 20 Feb 2016 19:10:58 +0530	[thread overview]
Message-ID: <56C86CEA.6080707@linux.vnet.ibm.com> (raw)
In-Reply-To: 1455894715.7770.22.camel@redhat.com

[-- Attachment #1: Type: text/plain, Size: 5180 bytes --]

Hi Mark,

Thanks for the patch. Indeed this is optimized one compared to what I've
proposed.

On Friday 19 February 2016 08:41 PM, Mark Wielaard wrote:
> Hi Ravi,
>
> On Fri, 2016-02-19 at 15:07 +0530, Ravi Bangoria wrote:
>> 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
> Thanks, that looks like what I expected.
> I also got access to a somewhat newer version of ubuntu ppc64le and that
> has an additional issue. It has the vmlinux file installed unreadable
> (except for root). That causes almost the same issue, but slightly
> differently, now no kernel at all is found... Although in that case it
> can be worked around be using /usr/lib/debug as base. But the main issue
> is exactly as you describe.

Can you please provide me system configurations like ubuntu versrion,
kernel version, stap version, elfutils version etc. I'll check if I'll 
be able
to get similar system.

>>> 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.
> That is probably because I was still a little confused myself :)
>
>> 1. Does this means change I've proposed is at wrong place i.e.
>> find_debuginfo
> Not wrong. It correctly finds the kernel. But it could be done a little
> more efficient I believe. With your change we do the search through all
> possible directories (and subdirs) twice. We could do it slightly more
> efficient by moving the logic into find_debuginfo_in_path itself.
>
> The issue is really that if find_debuginfo_in_path is passed in a "null"
> debuglink_name then it invents one (basename + .debug). But if it is
> "null" then that is really just one guess. We should as you indicate
> also try the basename itself. So that is what the attached patch does,
> it checks if debuglink_name is NULL and if we are checking in a debug
> directory (or subdirectory), but not the main file location, then we try
> both basename.debug and basename.
>
> That should do the same thing as your suggested patch, but makes it
> slightly more efficient. We try less directories/files. And if the
> kernel image exists we should find it earlier.
>
> Could you try out if this variant of the patch works for you?

I've tested your patch and it's working fine with Ubuntu 14.04 with 
kernel 3.13,
stap 2.3 and elfutils 0.165.

But I've a little doubt here. Here is the code snip of try_kernel_name
from libdwfl/linux-kernel-modules.c

     static int
     try_kernel_name (Dwfl *dwfl, char **fname, bool try_debug)
     {
LINE A:
       int fd = ((((dwfl->callbacks->debuginfo_path
                    ? *dwfl->callbacks->debuginfo_path : NULL)
                   ?: DEFAULT_DEBUGINFO_PATH)[0] == ':') ? -1
                 : TEMP_FAILURE_RETRY (open64 (*fname, O_RDONLY)));

       if (fd < 0)
         {
LINE B:
           /* look for "vmlinux" files.  */
           fd = INTUSE(dwfl_standard_find_debuginfo) (&fakemod, NULL, 
NULL, 0,
                                                      *fname, basename 
(*fname), 0,
&fakemod.debug.name);
           if (fd < 0 && try_debug)
LINE C:
             /* look for "vmlinux.debug" files.  */
             fd = INTUSE(dwfl_standard_find_debuginfo) (&fakemod, NULL, 
NULL, 0,
                                                        *fname, NULL, 0,
&fakemod.debug.name);

try_kernel_name is doing almost same thing what I have proposed. Now let's
say we want to go ahead with your patch, than call to 
dwfl_standard_find_debuginfo
in LINE C will look for both vmlinux and vmlinux.debug right? But it has 
already
checked for vmlinux in LINE B. So, in this case we have to modify 
try_kernel_name
as well.

Please correct me if I'm wrong.

Regards,
Ravi

             reply	other threads:[~2016-02-20 13:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-20 13:40 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-19 15:11 Mark Wielaard
2016-02-19  9:37 Ravi Bangoria
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=56C86CEA.6080707@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).