From: Andi Kleen <ak@muc.de>
To: Mark Gross <markgross@thegnar.org>
Cc: Andi Kleen <ak@muc.de>, Ingo Molnar <mingo@elte.hu>,
Alexander Viro <viro@math.psu.edu>,
S Vamsikrishna <vamsi_krishna@in.ibm.com>,
Ulrich Drepper <drepper@redhat.com>,
linux-kernel@vger.kernel.org,
NPT library mailing list <phil-list@redhat.com>
Subject: Re: [patch] thread-aware coredumps, 2.5.43-C3
Date: Fri, 18 Oct 2002 04:12:42 +0200 [thread overview]
Message-ID: <20021018021242.GA15853@averell> (raw)
In-Reply-To: <200210171835.21647.markgross@thegnar.org>
On Fri, Oct 18, 2002 at 03:35:21AM +0200, Mark Gross wrote:
> On Thursday 17 October 2002 06:10 pm, Andi Kleen wrote:
> > Ingo Molnar <mingo@elte.hu> writes:
> >
> >
> > [...]
> >
> > This is not directly related to mt coredumps, but for anybody hacking the
> > core dumper:
> >
> > it would be cool if error code/trapno were included in the coredump in some
> > elf note. It has always annoyed me that these were lost and they can
> > be very useful to diagnose crashes that are caused by kernel problems.
> >
> > -Andi
>
> What more do you want? You have all the registers, the mm and at least a
> dissasembly of the code, you even have the signr in the NT_PRSTATUS section.
I want the x86 CPU error code, which often has interesting clues on the problem.
trapno would be useful too. I suspect other CPUs have similar extended
state for exceptions.
I usually hack my kernel to printk() it, but having it in the coredump
would be more general and you can look at it later.
Eventually (in a future kernel) I would love to have the exception
handler save the last branch debugging registers of the CPU and the let the
core dumper put that into the dump too. Then you could easily
figure out what the program did shortly before the crash.
-Andi
next prev parent reply other threads:[~2002-10-18 2:07 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-08 12:09 [patch] thread-aware coredumps part 1, tcore-2.5.41-A6 Ingo Molnar
2002-10-08 13:30 ` mgross
2002-10-17 9:11 ` [patch] thread-aware coredumps, 2.5.43-C3 Ingo Molnar
2002-10-17 16:40 ` Daniel Jacobowitz
2002-10-21 14:29 ` Alan Cox
2002-10-21 14:54 ` Daniel Jacobowitz
2002-10-21 16:16 ` Alan Cox
2002-10-21 16:04 ` Daniel Jacobowitz
2002-10-17 21:07 ` mgross
2002-10-18 0:48 ` Daniel Jacobowitz
2002-10-18 13:57 ` Mark Gross
2002-10-18 14:03 ` Mark Gross
2002-10-19 13:26 ` Mark Kettenis
2002-10-19 19:26 ` Bill Davidsen
2002-10-19 19:34 ` Ulrich Drepper
2002-10-19 13:20 ` Mark Kettenis
2002-10-19 18:42 ` Mark Gross
2002-10-18 1:10 ` Andi Kleen
2002-10-18 1:35 ` Mark Gross
2002-10-18 2:12 ` Andi Kleen [this message]
2002-10-18 2:58 ` Mark Gross
2002-10-18 3:55 ` Daniel Jacobowitz
2002-10-18 14:00 ` mgross
2002-10-21 15:17 ` Pavel Machek
2002-11-03 7:32 ` Ulrich Drepper
2002-10-19 17:32 ` Ulrich Drepper
2002-10-18 2:23 ` Ulrich Drepper
2002-10-18 2:40 ` Andi Kleen
2002-10-08 18:04 ` [patch] thread-aware coredumps part 1, tcore-2.5.41-A6 mgross
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=20021018021242.GA15853@averell \
--to=ak@muc.de \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markgross@thegnar.org \
--cc=mingo@elte.hu \
--cc=phil-list@redhat.com \
--cc=vamsi_krishna@in.ibm.com \
--cc=viro@math.psu.edu \
/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.