[Crash-utility] [RFC v2] gcore: process core dump feature for crash utility
HATAYAMA Daisuke
d.hatayama at jp.fujitsu.com
Mon Aug 16 01:31:57 UTC 2010
From: Dave Anderson <anderson at redhat.com>
Subject: Re: [Crash-utility] [RFC v2] gcore: process core dump feature for crash utility
Date: Wed, 11 Aug 2010 10:11:22 -0400 (EDT)
>
> ----- "HATAYAMA Daisuke" <d.hatayama at jp.fujitsu.com> wrote:
>
>> Hello.
>>
>> This is the RFC version 2 of gcore sub-command that provides a process
>> core dump feature for crash utility.
>>
>> During the period from RFC v1, I had investigated how to restore
>> user-mode register values. The patch reflects the investigation.
>>
>> Any comments or suggestions are welcome.
>
> Hello Daisuke,
>
> I haven't had a chance to play with this, but thank you for transistioning
> this to an extension module. I say that especially due to the fact that you've
> essentially "ported" a huge amount of 2.6.34 kernel code to user space, and
> then tinkered with the memory accesses, etc., to adapt it to getting data
> from the dumpfile. Doing it that way is fine -- as long as you don't mind
> maintaining it.
>
> It should be noted that it's something that I try to avoid doing in the base
> crash utility if at all possible. The one place where I did do precisely what
> you did was the porting of the kernel's ia64 unwind code, which you'll note has
> since gone through 3 versions. The unwind_x86_32_64.c piece was started by IBM
> back before Jan Beulich's (temporary) x86 unwind code was pulled out of the kernel,
> but it's pretty much dead code now.
>
> In any case, what you have done is an impressive amount of work, and
> certainly worthy of being maintained in the extensions area. And BTW,
> *you* will be the maintainer, answer questions about it on the crash-utility
> mailing list, review/accept/reject other contributors patches to it, etc.
>
> But again, it's an impressive start. When you are satisfied with it, let
> me know. and I will store it on the crash-utility web-site, and include
> in the tar.gz/src.rpm files.
Hello, Dave.
Yes, I also think I want to avoid merely poted kernel source code
because it tends to lead directly to kernel-version dependency. In
this sense, I think it better to implement gcore in crash's own logic,
just as other part in crash, to achieve high maintainerbility.
The reason why the current version has been organized this way is the
fact that it was made just as simply a prototype for the purpose of
demo showing the program working actually well. Thus I think the next
task is to improve it: redesigning, cleaning, etc.
I will let you know when I complete the task I am considering now. In
summary, it's going to be the time after I finish the followings:
- support at least RHEL5 and RHEL6 on x86_64
- refactoring
* put kernel-version dependent part separately
* add a mechanism, like regset interface, for other developpers to
be able to smoothly add new support
- test
Also, I want to make some question if something I don't know occurs
during the work above.
Thanks.
HATAYAMA Daisuke
>
> Thanks,
> Dave
>
>
>>
>> Changes in short
>> ================
>>
>> The changes include:
>>
>> 1) implement a collection of user-space register values more
>> appropriately, but not ideally.
>>
>> 2) re-design gcore sub-command as an extension module
>>
>>
>> By (1), GDB's bt command displays backtrace normally.
>>
>> diffstat ouput
>>
>> Makefile | 6 +-
>> defs.h | 2 +
>> extensions/gcore.c | 21 +
>> extensions/gcore.mk | 48 +
>> extensions/libgcore/2.6.34/x86_64/gcore.c | 2033
>> +++++++++++++++++++++++++++++
>> extensions/libgcore/2.6.34/x86_64/gcore.h | 651 +++++++++
>> netdump.c | 27 +
>> tools.c | 1 -
>> 8 files changed, 2787 insertions(+), 2 deletions(-)
>>
>> Current Status
>> ==============
>>
>> I've continued to develop gcore sub-command, but this version is
>> still under development.
>>
>> Ultimately, I'm going to implement gcore as I described in RFC v1
>> and as I will explain in ``Detailed Changes and Issues'' below.
>>
>>
>> How to build and use
>> ====================
>>
>> I've attached the patchset to this mail.
>>
>> - crash-gcore-RFCv2.patch
>>
>> Please use crash version 5.0.5 on x86_64.
>>
>> Follow the next instructions:
>>
>> $ tar xf crash-5.0.5.tar.gz
>> $ cd crash-5.0.5/
>> $ patch -p 1 < crash-gcore-v2.patch
>> $ make
>> $ make extensions
>> $ crash <debuginfo> <vmcore> .... (*)
>> crash> extend gcore.so
>>
>> In (*), gcore.so is generated under the extensions/ directory.
>>
>>
>> Detailed Changes and Issues
>> ===========================
>>
>> 1) implement collection of user-space register values more
>> appropriately, but not ideally
>>
>> The previous version doesn't retrieve appropriate register values
>> because it doesn't consider save/restore operations at interrupts on
>> kernel at all.
>>
>> I've added restore operations according to which kinds of interrupts
>> the target task entered kernel-mode. See fill_pr_reg() in gcore.c.
>>
>> But unfortunately, the current version is still not ideal, since it
>> would take some time to do.
>>
>> More precisely, all part of user-mode registers are not always
>> restored. The full part is saved only at exceptions, NMI and some
>> kinds of system calls. At other kinds of interrupts, saved are
>> register values except for 6 callee-saved registers: rbp, rbx, r12,
>> r13, r14, r15.
>>
>> In theory, these can be restored using Call Frame Information
>> generated by a compiler as part of debugging information, whose
>> section name is .debug_frame, which tells us offsets of respective
>> callee-saved registers.
>>
>> But currently, I don't do this yet, since I don't find any useful
>> library to do this. Yes, I think I can implement it manually, but it
>> would take some time. I've of course found unwind_x86_32_64.c
>> providing related library but it looks to me unfinished.
>>
>> On the other hand, a frame pointer, rbp, can be restored by
>> unwinding it repeatedly until its address value reaches any
>> user-space address.
>>
>>
>> 2) re-design gcore sub-command as an extension module
>>
>> In respond to my previous post, Dave gave me a suggestion that gcore
>> subcommand should be provided as an extension module per kernel
>> versions and type of architecutes, since process core dump feature
>> inherently depends on kernel data structures.
>>
>> I agreed the suggestion and have tried to redesign the patchset.
>>
>> Although the current patchset merely moved gcore files into
>> ./extensions directory, I've also considered better design. That is,
>>
>> (1) architecture- or kernel-version independent part is provided
>> just under ./extensions
>>
>> (2) only architecture- or kernel-version specific part is provided as
>> certain extension module.
>>
>> The next directory structure depicts this shortly:
>>
>> crash-5.0.5/
>> extensions/
>> gcore.mk
>> gcore.c ... (1)
>> libgcore/ ... (2)
>> 2.6.34/
>> x86_64/
>> gcore_note.h
>> gcore_note.c
>>
>> I think it relatively easily feasible by porting regset interface in
>> kernel, which is used to implement ptrace feature, hiding
>> implementation details on many architectures.
>>
>> Also, it helps port kernel codes in gcore and maintain source codes
>> ranging over a variety of kernel versions on multiple architectures
>> uniformly.
>>
>> I'm going to re-implement this way in the next version. From that
>> version, I won't change gcore source code dramatically, change only
>> when adding newly extension modules.
>>
>>
>> Thanks
>> --
>> HATAYAMA Daisuke
>>
>> --
>> Crash-utility mailing list
>> Crash-utility at redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
More information about the Crash-utility
mailing list