All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Lan <jlan@sgi.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: kexec@lists.infradead.org, Bernhard Walle <bwalle@suse.de>,
	Dave Anderson <anderson@redhat.com>
Subject: Re: [PATCH] [makedumpfile] Follow debuginfo link of vmlinux file
Date: Tue, 29 May 2007 10:44:07 -0700	[thread overview]
Message-ID: <465C6667.2020207@sgi.com> (raw)
In-Reply-To: <20070529204311oomichi@mail.jp.nec.com>

Ken'ichi Ohmichi wrote:
> Hi Jay,
> 
> Sorry for the late response.
> 
> 2007/05/24 12:44:26 -0700, Jay Lan <jlan@sgi.com> wrote:
>> Bernhard Walle wrote:
>>> Hello,
>>>
>>> * Dave Anderson <anderson@redhat.com> [2007-05-24 20:31]:
>>>> The crash utility hides the details of there being a separate debug
>>>> file in the same way the gdb does when working with a binary executable
>>>> that has a separate debuginfo file.  It tries *not* to be ambiguous,
>>>> i.e., the point is to stay true to the "crash vmlinux vmcore" model.
>>> It's documented in the GDB documentation:
>>> http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154
>> Thanks for the pointer, Bernhard. I installed kernel-debuginfo rpm
>> but crash still failed to find the debug information... I had to
>> copy the kernel-<version>.debug to /boot for it to work.
>>
>> So, i think it is a good idea for makedumpfile to follow the same
>> convension as crash and gdb, Ken'ichi?
> 
> No, I don't think it is worthy that a kernel file is specified *only*
> for getting the path to a debuginfo file. It is smart to specify
> a debuginfo file directly.  The crash utility needs both a kernel
> file and a debuginfo file, but makedumpfile needs only a debuginfo
> file as I said.
> 
> BTW, I recommend using a makedumpfile's CONFIGFILE instead of a
> debuginfo file.  If a system has a CONFIGFILE, makedumpfile can
> run without a debuginfo file.  It is smaller than a debuginfo file,
> and it is easy to distribute it to each system.
> I don't think each system should have a debuginfo file, because the
> file is big and a user may analyze a dumpfile on a remote analysis
> system. 

Ohmichi San,

Any way to make kernel debugging easier is great news!!! However...

If i run makedumpfile -x option to produce a dumpfile as below:
 # makedumpfile -c -d 31 -x VMLINUX VMCORE DUMPFILE

The size of these files are:
  16468 -rw-------  1 jlan wheel   16983716 2007-05-29 10:23 DUMPFILE

1719048 -r--------  1 jlan wheel 1760303684 2007-05-24 11:35 VMCORE
  55488 -rwxr-xr-x  1 jlan wheel   56819470 2007-05-24 11:33 VMLINUX

and crash was able to read and analyze the DUMPFILE together with the
VMLINUX.

Now when i used makedumpfile -g option to generate a CONFIGFILE:

 # makedumpfile -g CONFIGFILE -x VMLINUX

the size of CONFIGFILE is only 696 bytes. Besides, makedumpfile
failed to generate a DUMPFILE using the CONFIGFILE:

 # makedumpfile -c -d 31 -i CONFIGFILE VMCORE DUMPFILE
 CONFIGFILE and VMCORE don't match.

 makedumpfile Failed.


I think the CONFIGFILE is too small to be good?

What did i miss here?

Thanks,
 - jay


> 
> 
> Thanks
> Ken'ichi Ohmichi


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2007-05-29 17:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-01 13:39 [PATCH] [makedumpfile] Follow debuginfo link of vmlinux file Bernhard Walle
2007-05-24  0:35 ` Ken'ichi Ohmichi
2007-05-24  6:54   ` Bernhard Walle
2007-05-24  7:09     ` Bernhard Walle
2007-05-24 17:21   ` Jay Lan
2007-05-24 18:31     ` Dave Anderson
2007-05-24 19:21       ` Bernhard Walle
2007-05-24 19:44         ` Jay Lan
2007-05-24 19:54           ` Bernhard Walle
2007-05-29 11:43     ` Ken'ichi Ohmichi
2007-05-29 17:44       ` Jay Lan [this message]
2007-05-29 18:42         ` Bernhard Walle

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=465C6667.2020207@sgi.com \
    --to=jlan@sgi.com \
    --cc=anderson@redhat.com \
    --cc=bwalle@suse.de \
    --cc=kexec@lists.infradead.org \
    --cc=oomichi@mxs.nes.nec.co.jp \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.