1:55 a.m.
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
One of the items in the bug list is the following:
DESCRIPTION:
User space enhancements:
- show user space stack backtrace, if present in the dump file,
- ability to link user space namelist (debug object files),
RESOLUTION STATUS: TBD
Is anyone currently working on this?
The items in the TODO list, with the exception of the first
one about the "search" command, are all essentially "wish-list"
items. They were originally requested to be put there by IBM
several years ago when the http://people.redhat.com/anderson
site was instantiated as the "upstream" source of the crash
utility.
The only item that I'm aware of that somebody is actually looking
into is the one regarding "local variables", where I believe the
guy looking into it is part of the IBM LTC in India. I don't
expect much to come out of it, though, because for one thing
it presumes that the crash utility's backtrace frame information
is etched in stone -- and with the exception of ia64 which has
unwind information actually built into the kernel -- the backtrace
is essentially a "best-guess" operation. So trying to pull local
arguments (or function arguments for that matter) from a
dubious source doesn't make a whole lot of sense.
As far as a user-space backtrace, I still think the way to go
is to work on creating a core dump file of the requested task,
and then use gdb externally on that core file, completely outside
of the crash utility. Trying to overload the crash utility with
a bunch of user-space stuff is something I don't have a lot of
interest in.
Dave
2:28 a.m.
New subject: user-space enhancements
Right. To be able to examine user space, you'd have to build an elf core file by
processing the desired task structure in the kdump file, find all the user pages,
etc.--essentially what elf_core_dump() does in a running kernel. Then you could use gdb
offline or the embedded gdb.
I understand your desire not to burden crash with user space stuff, although the
extensions facility seems to provide a mechanism for cleanly excluding such functionality
from the standard configuration. Just a thought.
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf
Of Dave Anderson
Sent: Thursday, December 04, 2008 3:25 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] user-space enhancements
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
One of the items in the bug list is the following:
DESCRIPTION:
User space enhancements:
- show user space stack backtrace, if present in the dump file,
- ability to link user space namelist (debug object files),
RESOLUTION STATUS: TBD
Is anyone currently working on this?
The items in the TODO list, with the exception of the first
one about the "search" command, are all essentially "wish-list"
items. They were originally requested to be put there by IBM
several years ago when the http://people.redhat.com/anderson
site was instantiated as the "upstream" source of the crash
utility.
The only item that I'm aware of that somebody is actually looking
into is the one regarding "local variables", where I believe the
guy looking into it is part of the IBM LTC in India. I don't
expect much to come out of it, though, because for one thing
it presumes that the crash utility's backtrace frame information
is etched in stone -- and with the exception of ia64 which has
unwind information actually built into the kernel -- the backtrace
is essentially a "best-guess" operation. So trying to pull local
arguments (or function arguments for that matter) from a
dubious source doesn't make a whole lot of sense.
As far as a user-space backtrace, I still think the way to go
is to work on creating a core dump file of the requested task,
and then use gdb externally on that core file, completely outside
of the crash utility. Trying to overload the crash utility with
a bunch of user-space stuff is something I don't have a lot of
interest in.
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2:43 a.m.
New subject: user-space enhancements
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
Right. To be able to examine user space, you'd have to build an
elf
core file by processing the desired task structure in the kdump file,
find all the user pages, etc.--essentially what elf_core_dump() does
in a running kernel. Then you could use gdb offline or the embedded
gdb.
Yep, that would be pretty cool... "gdb offline" that is.
I still don't think it makes sense to do anything on the user core
file from the embedded gdb, given it's been wired/hacked to work solely
as a crash utility slave.
I envision a command that would work something like, for example,
for PID 24677:
crash> core 24677
core.24677 created
crash>
where 24677 is the PID. As a template for gathering the core data,
the "vm -p" command shows you where all of the user pages are, and
the "bt" kernel entry point gives you the "last-known" register set.
Seems like it could work...
I understand your desire not to burden crash with user space stuff,
although the extensions facility seems to provide a mechanism for
cleanly excluding such functionality from the standard configuration.
Just a thought.
Absolutely -- that's precisely what it's there for.
But for that matter, after it's working nicely as an extension,
and if it can be cleanly, reliably and maintainably (word?) moved
into the base sources, I'm all for it.
Thanks,
Dave
4:04 a.m.
New subject: user-space enhancements
Hi,
One difficulty is that user's data may be swaped out.
Thanks
Itsuro Oda
On Thu, 4 Dec 2008 16:13:11 -0500 (EST)
Dave Anderson <anderson(a)redhat.com> wrote:
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
> Right. To be able to examine user space, you'd have to build an elf
> core file by processing the desired task structure in the kdump file,
> find all the user pages, etc.--essentially what elf_core_dump() does
> in a running kernel. Then you could use gdb offline or the embedded
> gdb.
Yep, that would be pretty cool... "gdb offline" that is.
I still don't think it makes sense to do anything on the user core
file from the embedded gdb, given it's been wired/hacked to work solely
as a crash utility slave.
I envision a command that would work something like, for example,
for PID 24677:
crash> core 24677
core.24677 created
crash>
where 24677 is the PID. As a template for gathering the core data,
the "vm -p" command shows you where all of the user pages are, and
the "bt" kernel entry point gives you the "last-known" register set.
Seems like it could work...
> I understand your desire not to burden crash with user space stuff,
> although the extensions facility seems to provide a mechanism for
> cleanly excluding such functionality from the standard configuration.
> Just a thought.
Absolutely -- that's precisely what it's there for.
But for that matter, after it's working nicely as an extension,
and if it can be cleanly, reliably and maintainably (word?) moved
into the base sources, I'm all for it.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Itsuro ODA <oda(a)valinux.co.jp>
3:36 a.m.
New subject: user-space enhancements
There was a group at IBM (Stefan Schlosser <sschloss(a)de.ibm.com>)
a few years ago which set up stuff to generate
a elf corefile for a user space process for lcrash.
We ported it to crash as a loadable extension, but only did the i386
stuff.
If there's enough interest we could see about liberating our internal
code.
-castor
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Bradshaw, James
Sent: Thursday, December 04, 2008 12:58 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: RE: [Crash-utility] user-space enhancements
Right. To be able to examine user space, you'd have to build an elf core
file by processing the desired task structure in the kdump file, find
all
the user pages, etc.--essentially what elf_core_dump() does in a running
kernel. Then you could use gdb offline or the embedded gdb.
I understand your desire not to burden crash with user space stuff,
although the extensions facility seems to provide a mechanism for
cleanly
excluding such functionality from the standard configuration. Just a
thought.
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: Thursday, December 04, 2008 3:25 PM
To: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] user-space enhancements
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
One of the items in the bug list is the following:
DESCRIPTION:
User space enhancements:
- show user space stack backtrace, if present in the dump file,
- ability to link user space namelist (debug object files),
RESOLUTION STATUS: TBD
Is anyone currently working on this?
The items in the TODO list, with the exception of the first
one about the "search" command, are all essentially "wish-list"
items. They were originally requested to be put there by IBM
several years ago when the http://people.redhat.com/anderson
site was instantiated as the "upstream" source of the crash
utility.
The only item that I'm aware of that somebody is actually looking
into is the one regarding "local variables", where I believe the
guy looking into it is part of the IBM LTC in India. I don't
expect much to come out of it, though, because for one thing
it presumes that the crash utility's backtrace frame information
is etched in stone -- and with the exception of ia64 which has
unwind information actually built into the kernel -- the backtrace
is essentially a "best-guess" operation. So trying to pull local
arguments (or function arguments for that matter) from a
dubious source doesn't make a whole lot of sense.
As far as a user-space backtrace, I still think the way to go
is to work on creating a core dump file of the requested task,
and then use gdb externally on that core file, completely outside
of the crash utility. Trying to overload the crash utility with
a bunch of user-space stuff is something I don't have a lot of
interest in.
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
This email and any attachments thereto may contain private, confidential, and privileged
material for the sole use of the intended recipient. Any review, copying, or distribution
of this email (or any attachments) by others is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and permanently delete the
original and any copies of this email and any attachments thereto.
3:05 p.m.
New subject: user-space enhancements
Am Donnerstag, den 04.12.2008, 14:06 -0800 schrieb Castor Fu:
There was a group at IBM (Stefan Schlosser
<sschloss(a)de.ibm.com>)
a few years ago which set up stuff to generate
a elf corefile for a user space process for lcrash.
Stefan did that as diploma thesis in our department at IBM. The ugly
part was the swap file handling. The swap files had to be saved after a
dump in order to access all user space memory. We added the save
function in lcrash:
lcrash -S <swapdump>
to generate a dump-file containing all used swapped out pages of all
swap areas.
And we added an extra parameter <swapdump> when starting lcrash to
analyze the dump:
lcrash map.x dump.x kerntypes.x <swapdump>
Here the posting on the lkcd mailing list:
http://sourceforge.net/mailarchive/message.php?msg_id=OF7160ABF7.B54F4970...
But the code was never integrated officially in lcrash.
Michael
7:05 p.m.
New subject: user-space enhancements
Thanks. I gather that lkcd/lcrash was an earlier effort unrelated to crash. Is that
correct?
-----Original Message-----
From: crash-utility-bounces(a)redhat.com [mailto:crash-utility-bounces@redhat.com] On Behalf
Of Michael Holzheu
Sent: Friday, December 05, 2008 4:35 AM
To: Discussion list for crash utility usage, maintenance and development
Cc: Dan Stein
Subject: RE: [Crash-utility] user-space enhancements
Am Donnerstag, den 04.12.2008, 14:06 -0800 schrieb Castor Fu:
There was a group at IBM (Stefan Schlosser
<sschloss(a)de.ibm.com>)
a few years ago which set up stuff to generate
a elf corefile for a user space process for lcrash.
Stefan did that as diploma thesis in our department at IBM. The ugly
part was the swap file handling. The swap files had to be saved after a
dump in order to access all user space memory. We added the save
function in lcrash:
lcrash -S <swapdump>
to generate a dump-file containing all used swapped out pages of all
swap areas.
And we added an extra parameter <swapdump> when starting lcrash to
analyze the dump:
lcrash map.x dump.x kerntypes.x <swapdump>
Here the posting on the lkcd mailing list:
http://sourceforge.net/mailarchive/message.php?msg_id=OF7160ABF7.B54F4970...
But the code was never integrated officially in lcrash.
Michael
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2:55 p.m.
New subject: user-space enhancements
Hi,
We ported it to crash as a loadable extension, but only did the i386
stuff.
If there's enough interest we could see about liberating our internal
code.
Cool.
I also have such crash extention module works only on x86-64...
and tested only with 2.6.10 and 2.6.20 .
# crash -s vmlinux-2.6.20-1.2320.fc5 /mnt/fc5/var/crash/2008-01-28-18
\:17/vmcore
:
crash> extend elfcoredump.so
elfcoredump.so: shared object loaded
crash> elfdump 1
elfdump: write elfcore.1 done...
crash>
# gdb /sbin/init elfcore.1
:
To enable dump shmem, add -s option .
But unfortunately , the module is coredump_filter unaware.
and has a lots TBD code .
BTW, Oda-san mentioned page swapout case on another thread ,
in that case , I decided simply seek to next page (same as ZERO page case).
sigh... i know its incorrect.
I think this module contains incomplete functionality , but
should be maintained in crash community .
Castor, how about merge mine and your i386 module ?
Thanks.
Seigo Iguchi.
From: "Castor Fu" <Castor.Fu(a)3PAR.com>
Subject: RE: [Crash-utility] user-space enhancements
Date: Thu, 4 Dec 2008 14:06:29 -0800
> There was a group at IBM (Stefan Schlosser <sschloss(a)de.ibm.com>)
> a few years ago which set up stuff to generate
> a elf corefile for a user space process for lcrash.
>
We ported it to crash as a loadable extension, but only did the i386
stuff.
If there's enough interest we could see about liberating our internal
code.
>
> -castor
>
>
>
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Bradshaw, James
> Sent: Thursday, December 04, 2008 12:58 PM
> To: Discussion list for crash utility usage, maintenance and development
> Subject: RE: [Crash-utility] user-space enhancements
>
>
> Right. To be able to examine user space, you'd have to build an elf core
>
> file by processing the desired task structure in the kdump file, find
> all
> the user pages, etc.--essentially what elf_core_dump() does in a running
>
> kernel. Then you could use gdb offline or the embedded gdb.
>
> I understand your desire not to burden crash with user space stuff,
> although the extensions facility seems to provide a mechanism for
> cleanly
> excluding such functionality from the standard configuration. Just a
> thought.
>
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
> Sent: Thursday, December 04, 2008 3:25 PM
> To: Discussion list for crash utility usage, maintenance and development
> Subject: Re: [Crash-utility] user-space enhancements
>
>
> ----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
>
> > One of the items in the bug list is the following:
> >
> > DESCRIPTION:
> > User space enhancements:
> > - show user space stack backtrace, if present in the dump file,
> > - ability to link user space namelist (debug object files),
> >
> > RESOLUTION STATUS: TBD
> >
> > Is anyone currently working on this?
>
> The items in the TODO list, with the exception of the first
> one about the "search" command, are all essentially "wish-list"
> items. They were originally requested to be put there by IBM
> several years ago when the http://people.redhat.com/anderson
> site was instantiated as the "upstream" source of the crash
> utility.
>
> The only item that I'm aware of that somebody is actually looking
> into is the one regarding "local variables", where I believe the
> guy looking into it is part of the IBM LTC in India. I don't
> expect much to come out of it, though, because for one thing
> it presumes that the crash utility's backtrace frame information
> is etched in stone -- and with the exception of ia64 which has
> unwind information actually built into the kernel -- the backtrace
> is essentially a "best-guess" operation. So trying to pull local
> arguments (or function arguments for that matter) from a
> dubious source doesn't make a whole lot of sense.
>
> As far as a user-space backtrace, I still think the way to go
> is to work on creating a core dump file of the requested task,
> and then use gdb externally on that core file, completely outside
> of the crash utility. Trying to overload the crash utility with
> a bunch of user-space stuff is something I don't have a lot of
> interest in.
>
> Dave
>
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> This email and any attachments thereto may contain private, confidential, and
privileged material for the sole use of the intended recipient. Any review, copying, or
distribution of this email (or any attachments) by others is strictly prohibited. If you
are not the intended recipient, please contact the sender immediately and permanently
delete the original and any copies of this email and any attachments thereto.
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
5:25 a.m.
New subject: user-space enhancements
I don't really have resources to devote to merging my code, but I can
probably send you what I have. Our system usually doesn't
have the critical processes swapped at all, so it's not something
that I've worried about.
Seigo, it sounds like you're situation is similar to mine. As I said
before, I can look into making sure it's ok to release our code.
-castor
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of S.Iguchi
Sent: Monday, December 08, 2008 1:26 AM
To: crash-utility(a)redhat.com
Cc: Castor Fu
Subject: Re: [Crash-utility] user-space enhancements
Hi,
We ported it to crash as a loadable extension, but only did the i386
stuff.
If there's enough interest we could see about liberating our internal
code.
Cool.
I also have such crash extention module works only on x86-64...
and tested only with 2.6.10 and 2.6.20 .
# crash -s vmlinux-2.6.20-1.2320.fc5 /mnt/fc5/var/crash/2008-01-28-18
\:17/vmcore
:
crash> extend elfcoredump.so
elfcoredump.so: shared object loaded
crash> elfdump 1
elfdump: write elfcore.1 done...
crash>
# gdb /sbin/init elfcore.1
:
To enable dump shmem, add -s option .
But unfortunately , the module is coredump_filter unaware.
and has a lots TBD code .
BTW, Oda-san mentioned page swapout case on another thread ,
in that case , I decided simply seek to next page (same as ZERO page
case).
sigh... i know its incorrect.
I think this module contains incomplete functionality , but
should be maintained in crash community .
Castor, how about merge mine and your i386 module ?
Thanks.
Seigo Iguchi.
From: "Castor Fu" <Castor.Fu(a)3PAR.com>
Subject: RE: [Crash-utility] user-space enhancements
Date: Thu, 4 Dec 2008 14:06:29 -0800
> There was a group at IBM (Stefan Schlosser <sschloss(a)de.ibm.com>)
> a few years ago which set up stuff to generate
> a elf corefile for a user space process for lcrash.
>
We ported it to crash as a loadable extension, but only did the i386
stuff.
If there's enough interest we could see about liberating our internal
code.
>
> -castor
>
>
>
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Bradshaw, James
> Sent: Thursday, December 04, 2008 12:58 PM
> To: Discussion list for crash utility usage, maintenance and
development
Subject: RE: [Crash-utility] user-space enhancements
Right. To be able to examine user space, you'd have to build an elf
core
file by processing the desired task structure in the kdump file, find
all
the user pages, etc.--essentially what elf_core_dump() does in a
running
kernel. Then you could use gdb offline or the embedded gdb.
I understand your desire not to burden crash with user space stuff,
although the extensions facility seems to provide a mechanism for
cleanly
excluding such functionality from the standard configuration. Just a
thought.
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: Thursday, December 04, 2008 3:25 PM
To: Discussion list for crash utility usage, maintenance and
development
Subject: Re: [Crash-utility] user-space enhancements
----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
> One of the items in the bug list is the following:
>
> DESCRIPTION:
> User space enhancements:
> - show user space stack backtrace, if present in the dump file,
> - ability to link user space namelist (debug object files),
>
> RESOLUTION STATUS: TBD
>
> Is anyone currently working on this?
The items in the TODO list, with the exception of the first
one about the "search" command, are all essentially "wish-list"
items. They were originally requested to be put there by IBM
several years ago when the http://people.redhat.com/anderson
site was instantiated as the "upstream" source of the crash
utility.
The only item that I'm aware of that somebody is actually looking
into is the one regarding "local variables", where I believe the
guy looking into it is part of the IBM LTC in India. I don't
expect much to come out of it, though, because for one thing
it presumes that the crash utility's backtrace frame information
is etched in stone -- and with the exception of ia64 which has
unwind information actually built into the kernel -- the backtrace
is essentially a "best-guess" operation. So trying to pull local
arguments (or function arguments for that matter) from a
dubious source doesn't make a whole lot of sense.
As far as a user-space backtrace, I still think the way to go
is to work on creating a core dump file of the requested task,
and then use gdb externally on that core file, completely outside
of the crash utility. Trying to overload the crash utility with
a bunch of user-space stuff is something I don't have a lot of
interest in.
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
This email and any attachments thereto may contain private,
confidential, and
privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any
attachments) by others is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and any
attachments thereto.
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
This email and any attachments thereto may contain private, confidential, and privileged
material for the sole use of the intended recipient. Any review, copying, or distribution
of this email (or any attachments) by others is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and permanently delete the
original and any copies of this email and any attachments thereto.
9:54 a.m.
New subject: user-space enhancements
Castor ,
thanks to reply.
I also donot have enough resource. :)
and also same thing is swapout case is not significant issue for
this enhancement in our system , because most of our applications call mlock or
shmctl(.. SHM_LOCK) .
(it probably is better to put this item in TODO list.)
OK, I'll try to dump latest kernel and elfdump some processes.
and do some cleanup. if done , I'll post it on this ML.
----
Seigo Iguchi
From: "Castor Fu" <Castor.Fu(a)3PAR.com>
Subject: RE: [Crash-utility] user-space enhancements
Date: Fri, 12 Dec 2008 15:55:44 -0800
I don't really have resources to devote to merging my code, but I
can
probably send you what I have. Our system usually doesn't
have the critical processes swapped at all, so it's not something
that I've worried about.
Seigo, it sounds like you're situation is similar to mine. As I said
before, I can look into making sure it's ok to release our code.
-castor
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of S.Iguchi
Sent: Monday, December 08, 2008 1:26 AM
To: crash-utility(a)redhat.com
Cc: Castor Fu
Subject: Re: [Crash-utility] user-space enhancements
Hi,
> We ported it to crash as a loadable extension, but only did the i386
> stuff.
>
> If there's enough interest we could see about liberating our internal
> code.
Cool.
I also have such crash extention module works only on x86-64...
and tested only with 2.6.10 and 2.6.20 .
# crash -s vmlinux-2.6.20-1.2320.fc5 /mnt/fc5/var/crash/2008-01-28-18
\:17/vmcore
:
crash> extend elfcoredump.so
elfcoredump.so: shared object loaded
crash> elfdump 1
elfdump: write elfcore.1 done...
crash>
# gdb /sbin/init elfcore.1
:
To enable dump shmem, add -s option .
But unfortunately , the module is coredump_filter unaware.
and has a lots TBD code .
BTW, Oda-san mentioned page swapout case on another thread ,
in that case , I decided simply seek to next page (same as ZERO page
case).
sigh... i know its incorrect.
I think this module contains incomplete functionality , but
should be maintained in crash community .
Castor, how about merge mine and your i386 module ?
Thanks.
Seigo Iguchi.
From: "Castor Fu" <Castor.Fu(a)3PAR.com>
Subject: RE: [Crash-utility] user-space enhancements
Date: Thu, 4 Dec 2008 14:06:29 -0800
> There was a group at IBM (Stefan Schlosser <sschloss(a)de.ibm.com>)
> a few years ago which set up stuff to generate
> a elf corefile for a user space process for lcrash.
>
> We ported it to crash as a loadable extension, but only did the i386
> stuff.
>
> If there's enough interest we could see about liberating our internal
> code.
>
> -castor
>
>
>
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Bradshaw, James
> Sent: Thursday, December 04, 2008 12:58 PM
> To: Discussion list for crash utility usage, maintenance and
development
> Subject: RE: [Crash-utility] user-space enhancements
>
>
> Right. To be able to examine user space, you'd have to build an elf
core
>
> file by processing the desired task structure in the kdump file, find
> all
> the user pages, etc.--essentially what elf_core_dump() does in a
running
>
> kernel. Then you could use gdb offline or the embedded gdb.
>
> I understand your desire not to burden crash with user space stuff,
> although the extensions facility seems to provide a mechanism for
> cleanly
> excluding such functionality from the standard configuration. Just a
> thought.
>
> -----Original Message-----
> From: crash-utility-bounces(a)redhat.com
> [mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
> Sent: Thursday, December 04, 2008 3:25 PM
> To: Discussion list for crash utility usage, maintenance and
development
> Subject: Re: [Crash-utility] user-space enhancements
>
>
> ----- "James Bradshaw" <jbradsha(a)enterasys.com> wrote:
>
> > One of the items in the bug list is the following:
> >
> > DESCRIPTION:
> > User space enhancements:
> > - show user space stack backtrace, if present in the dump file,
> > - ability to link user space namelist (debug object files),
> >
> > RESOLUTION STATUS: TBD
> >
> > Is anyone currently working on this?
>
> The items in the TODO list, with the exception of the first
> one about the "search" command, are all essentially "wish-list"
> items. They were originally requested to be put there by IBM
> several years ago when the http://people.redhat.com/anderson
> site was instantiated as the "upstream" source of the crash
> utility.
>
> The only item that I'm aware of that somebody is actually looking
> into is the one regarding "local variables", where I believe the
> guy looking into it is part of the IBM LTC in India. I don't
> expect much to come out of it, though, because for one thing
> it presumes that the crash utility's backtrace frame information
> is etched in stone -- and with the exception of ia64 which has
> unwind information actually built into the kernel -- the backtrace
> is essentially a "best-guess" operation. So trying to pull local
> arguments (or function arguments for that matter) from a
> dubious source doesn't make a whole lot of sense.
>
> As far as a user-space backtrace, I still think the way to go
> is to work on creating a core dump file of the requested task,
> and then use gdb externally on that core file, completely outside
> of the crash utility. Trying to overload the crash utility with
> a bunch of user-space stuff is something I don't have a lot of
> interest in.
>
> Dave
>
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> This email and any attachments thereto may contain private,
confidential, and privileged material for the sole use of the intended
recipient. Any review, copying, or distribution of this email (or any
attachments) by others is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and any
attachments thereto.
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
This email and any attachments thereto may contain private, confidential, and privileged
material for the sole use of the intended recipient. Any review, copying, or distribution
of this email (or any attachments) by others is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and permanently delete the
original and any copies of this email and any attachments thereto.
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
6053
days inactive
6064
days old
devel@lists.crash-utility.osci.io
9 comments
6 participants
participants (6)
-
Bradshaw, James -
Castor Fu -
Dave Anderson -
Itsuro ODA -
Michael Holzheu -
S.Iguchi