FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default gco process core dump feature for crash utility

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.


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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 11:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org