From: "Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
To: Jay Lan <jlan@sgi.com>
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 20:43:11 +0900 [thread overview]
Message-ID: <20070529204311oomichi@mail.jp.nec.com> (raw)
In-Reply-To: <4655C9B3.7060903@sgi.com>
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.
Thanks
Ken'ichi Ohmichi
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2007-05-29 11:43 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 [this message]
2007-05-29 17:44 ` Jay Lan
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=20070529204311oomichi@mail.jp.nec.com \
--to=oomichi@mxs.nes.nec.co.jp \
--cc=anderson@redhat.com \
--cc=bwalle@suse.de \
--cc=jlan@sgi.com \
--cc=kexec@lists.infradead.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 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.