10:02 a.m.
Hi All
My laptop has 64bit fc6 and crash utility. One of the development
machine is 32bit RHEL4. whenever i try to open the dump generated by
that box, I got a unknown format error. i can analyze the dump with the
crash from that RHEL4, and also my laptop can analyze the dump from
another 64bit RHEL4.
so my question is how to allow the crash in a 64bit box to open a dump
from a 32bit box?
Thanks!
Ming
10:17 a.m.
Ming Zhang wrote:
Hi All
My laptop has 64bit fc6 and crash utility. One of the development
machine is 32bit RHEL4. whenever i try to open the dump generated by
that box, I got a unknown format error. i can analyze the dump with the
crash from that RHEL4, and also my laptop can analyze the dump from
another 64bit RHEL4.
so my question is how to allow the crash in a 64bit box to open a dump
from a 32bit box?
Thanks!
Ming
Try copying a 32-bit crash utility to the 64-bit laptop,
and running it from there.
Here's an example:
# uname -m
x86_64
# file ./crash
./crash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5,
dynamically linked (uses shared
libs), not stripped
# ./crash /tmp/vm*
crash 4.0-3.21
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
KERNEL: /tmp/vmlinux
DEBUG KERNEL: /tmp/vmlinux-2.4.21-1.1931.2.421.ent.debug
DUMPFILE: /tmp/vmcore
CPUS: 1
DATE: Tue Sep 9 18:02:05 2003
UPTIME: 05:04:13
LOAD AVERAGE: 9.96, 10.56, 10.89
TASKS: 72
NODENAME: moe.lab.boston.redhat.com
RELEASE: 2.4.21pre1
VERSION: #3 Tue Sep 9 14:13:17 EDT 2003
MACHINE: i686 (501 Mhz)
MEMORY: 128 MB
PANIC: "Oops: 0002" (check log for details)
PID: 3701
COMMAND: "sh"
TASK: c791c000
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash>
Dave
10:21 a.m.
On Tue, 2007-03-27 at 10:17 -0500, Dave Anderson wrote:
Ming Zhang wrote:
> Hi All
>
> My laptop has 64bit fc6 and crash utility. One of the development
> machine is 32bit RHEL4. whenever i try to open the dump generated
> by
> that box, I got a unknown format error. i can analyze the dump with
> the
> crash from that RHEL4, and also my laptop can analyze the dump from
> another 64bit RHEL4.
>
> so my question is how to allow the crash in a 64bit box to open a
> dump
> from a 32bit box?
>
> Thanks!
>
> Ming
>
>
>
Try copying a 32-bit crash utility to the 64-bit laptop,
and running it from there.
i thought about this. could u enlighten us why single crash cannot do
that? implementation limitation or more deeper reason?
Here's an example:
# uname -m
x86_64
# file ./crash
./crash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
# ./crash /tmp/vm*
crash 4.0-3.21
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public
License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for
details.
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu"...
KERNEL: /tmp/vmlinux
DEBUG KERNEL: /tmp/vmlinux-2.4.21-1.1931.2.421.ent.debug
DUMPFILE: /tmp/vmcore
CPUS: 1
DATE: Tue Sep 9 18:02:05 2003
UPTIME: 05:04:13
LOAD AVERAGE: 9.96, 10.56, 10.89
TASKS: 72
NODENAME: moe.lab.boston.redhat.com
RELEASE: 2.4.21pre1
VERSION: #3 Tue Sep 9 14:13:17 EDT 2003
MACHINE: i686 (501 Mhz)
MEMORY: 128 MB
PANIC: "Oops: 0002" (check log for details)
PID: 3701
COMMAND: "sh"
TASK: c791c000
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash>
Dave
10:28 a.m.
Ming Zhang wrote:
On Tue, 2007-03-27 at 10:17 -0500, Dave Anderson wrote:
> Ming Zhang wrote:
> > Hi All
> >
> > My laptop has 64bit fc6 and crash utility. One of the development
> > machine is 32bit RHEL4. whenever i try to open the dump generated
> > by
> > that box, I got a unknown format error. i can analyze the dump with
> > the
> > crash from that RHEL4, and also my laptop can analyze the dump from
> > another 64bit RHEL4.
> >
> > so my question is how to allow the crash in a 64bit box to open a
> > dump
> > from a 32bit box?
> >
> > Thanks!
> >
> > Ming
> >
> >
> >
> Try copying a 32-bit crash utility to the 64-bit laptop,
> and running it from there.
i thought about this. could u enlighten us why single crash cannot do
that? implementation limitation or more deeper reason?
Most definitely an implementation limitation. The source only
builds in the machine-specific source code based upon the
host machine type.
>
> Here's an example:
>
> # uname -m
> x86_64
> # file ./crash
> ./crash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
> GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
> # ./crash /tmp/vm*
>
> crash 4.0-3.21
> Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005 NEC Corporation
> Copyright (C) 1999, 2002 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public
> License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> GNU gdb 6.1
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i686-pc-linux-gnu"...
>
> KERNEL: /tmp/vmlinux
> DEBUG KERNEL: /tmp/vmlinux-2.4.21-1.1931.2.421.ent.debug
> DUMPFILE: /tmp/vmcore
> CPUS: 1
> DATE: Tue Sep 9 18:02:05 2003
> UPTIME: 05:04:13
> LOAD AVERAGE: 9.96, 10.56, 10.89
> TASKS: 72
> NODENAME: moe.lab.boston.redhat.com
> RELEASE: 2.4.21pre1
> VERSION: #3 Tue Sep 9 14:13:17 EDT 2003
> MACHINE: i686 (501 Mhz)
> MEMORY: 128 MB
> PANIC: "Oops: 0002" (check log for details)
> PID: 3701
> COMMAND: "sh"
> TASK: c791c000
> CPU: 0
> STATE: TASK_RUNNING (PANIC)
>
> crash>
>
> Dave
>
10:33 a.m.
On Tue, 2007-03-27 at 10:28 -0500, Dave Anderson wrote:
> > Try copying a 32-bit crash utility to the 64-bit laptop,
> > and running it from there.
>
> i thought about this. could u enlighten us why single crash cannot
do
> that? implementation limitation or more deeper reason?
>
Most definitely an implementation limitation. The source only
builds in the machine-specific source code based upon the
host machine type.
ic. so it could be more flexible and most code is ready. thanks for
explanation.
ming
10:46 a.m.
Hi Dave,
This seemed like the perfect opportunity to ask if this proves
there might be a market for my cross-compilation additions to
crash.
Not the byte-swapping stuff. The lack of hosannas from your
end has caused me to tearfully conclude that I didn't make the
cut.
So let me propose a couple of things:
1) How about if I just submit my diffs that allowed for
cross-compilation of the x86 version on a 64-bit platform?
Plus any bug fixes or other minor amendations I had?
2) I might have a better solution to this whole "how to do
byte-swapping, where needed, without confusing everything
in sight?" A partial solution, anyway.
The model would be based on the difference between malloc
and calloc calling sequences. With malloc, you just specify
the length you want. With calloc, you specify a number of
items and the length of each item.
We could have a readmem variant that incorporates the calloc
style. Don't specify a length, specify an item count and an
item length. Then the byte swappers could hook into this,
but ordinary code would still do a readmem-style thing.
Would this be any better?
Regards,
-- David "that's a little more information than I needed" Wright
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Dave Anderson
Sent: Tuesday, March 27, 2007 11:29 AM
To: blackmagic02881(a)gmail.com
Cc: Discussion list for crash utility usage, maintenance and
development
Subject: Re: [Crash-utility] how to analyze a 32bit dump with
a 64bit crash
Ming Zhang wrote:
> On Tue, 2007-03-27 at 10:17 -0500, Dave Anderson wrote:
> > Ming Zhang wrote:
> > > Hi All
> > >
> > > My laptop has 64bit fc6 and crash utility. One of the
development
> > > machine is 32bit RHEL4. whenever i try to open the dump
generated
> > > by
> > > that box, I got a unknown format error. i can analyze
the dump with
> > > the
> > > crash from that RHEL4, and also my laptop can analyze
the dump from
> > > another 64bit RHEL4.
> > >
> > > so my question is how to allow the crash in a 64bit box
to open a
> > > dump
> > > from a 32bit box?
> > >
> > > Thanks!
> > >
> > > Ming
> > >
> > >
> > >
> > Try copying a 32-bit crash utility to the 64-bit laptop,
> > and running it from there.
>
> i thought about this. could u enlighten us why single crash
cannot do
> that? implementation limitation or more deeper reason?
>
Most definitely an implementation limitation. The source only
builds in the machine-specific source code based upon the
host machine type.
>
> >
> > Here's an example:
> >
> > # uname -m
> > x86_64
> > # file ./crash
> > ./crash: ELF 32-bit LSB executable, Intel 80386, version
1 (SYSV), for
> > GNU/Linux 2.2.5, dynamically linked (uses shared libs),
not stripped
> > # ./crash /tmp/vm*
> >
> > crash 4.0-3.21
> > Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Red Hat, Inc.
> > Copyright (C) 2004, 2005, 2006 IBM Corporation
> > Copyright (C) 1999-2006 Hewlett-Packard Co
> > Copyright (C) 2005, 2006 Fujitsu Limited
> > Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> > Copyright (C) 2005 NEC Corporation
> > Copyright (C) 1999, 2002 Silicon Graphics, Inc.
> > Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> > This program is free software, covered by the GNU General Public
> > License,
> > and you are welcome to change it and/or distribute copies
of it under
> > certain conditions. Enter "help copying" to see the conditions.
> > This program has absolutely no warranty. Enter "help
warranty" for
> > details.
> >
> > GNU gdb 6.1
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public
License, and
> > you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for
> > details.
> > This GDB was configured as "i686-pc-linux-gnu"...
> >
> > KERNEL: /tmp/vmlinux
> > DEBUG KERNEL: /tmp/vmlinux-2.4.21-1.1931.2.421.ent.debug
> > DUMPFILE: /tmp/vmcore
> > CPUS: 1
> > DATE: Tue Sep 9 18:02:05 2003
> > UPTIME: 05:04:13
> > LOAD AVERAGE: 9.96, 10.56, 10.89
> > TASKS: 72
> > NODENAME: moe.lab.boston.redhat.com
> > RELEASE: 2.4.21pre1
> > VERSION: #3 Tue Sep 9 14:13:17 EDT 2003
> > MACHINE: i686 (501 Mhz)
> > MEMORY: 128 MB
> > PANIC: "Oops: 0002" (check log for details)
> > PID: 3701
> > COMMAND: "sh"
> > TASK: c791c000
> > CPU: 0
> > STATE: TASK_RUNNING (PANIC)
> >
> > crash>
> >
> > Dave
> >
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
11:05 a.m.
"Wright, David" wrote:
Hi Dave,
This seemed like the perfect opportunity to ask if this proves
there might be a market for my cross-compilation additions to
crash.
Maybe you and the MontaVista guys could get together
and come up with a common cross-compilation plan.
Not the byte-swapping stuff. The lack of hosannas from your
end has caused me to tearfully conclude that I didn't make the
cut.
So let me propose a couple of things:
1) How about if I just submit my diffs that allowed for
cross-compilation of the x86 version on a 64-bit platform?
Plus any bug fixes or other minor amendations I had?
I guess I missed that part. I thought the patch was only for
supporting the MIPS 4000 on a 32-bit x86 platform? If you're
only talking about supporting x86 on x86_64, why bother?
2) I might have a better solution to this whole "how to do
byte-swapping, where needed, without confusing everything
in sight?" A partial solution, anyway.
The model would be based on the difference between malloc
and calloc calling sequences. With malloc, you just specify
the length you want. With calloc, you specify a number of
items and the length of each item.
We could have a readmem variant that incorporates the calloc
style. Don't specify a length, specify an item count and an
item length. Then the byte swappers could hook into this,
but ordinary code would still do a readmem-style thing.
Would this be any better?
I suppose you could encode a whole bunch of stuff into the current
readmem()'s "error_handle" flag. It only uses 3 bits now, and it seems
that there would only be a need for one readmem(), which could do all manner
of different things based upon the byte-swapping or whatever flags,
all of which could be conditionally no-op flags for non-cross-compiled
versions.
Dave
10:54 a.m.
Am Tuesday, den 27.03.2007, 11:05 -0500 schrieb Dave Anderson:
[cross-debug or cross-endianess or byte-swapping]
I suppose you could encode a whole bunch of stuff into the current
readmem()'s "error_handle" flag. It only uses 3 bits now, and it seems
that there would only be a need for one readmem(), which could do all manner
of different things based upon the byte-swapping or whatever flags,
all of which could be conditionally no-op flags for non-cross-compiled
versions.
There's patch from Corey Minyard that changes the ULONG etc. macros to
handle endianess. It's for ppc-on-x86 cross-debug and against an old
version of crash, you can get it from the wayback machine:
http://web.archive.org/web/20041116221120/http://home.comcast.net/~minyar...
Using readmem you need to read long/short values one-by-one anyway
unless you have a list of data with the same type. IMHO the ULONG
approach is simpler and clearer (makes code more readable). It's some
work to have all memory accesses use ULONG etc. but you might have to do
the same with the readmem approach.
Rainer
10:38 a.m.
Dave Anderson wrote:
"Wright, David" wrote:
> Hi Dave,
>
> This seemed like the perfect opportunity to ask if this proves
> there might be a market for my cross-compilation additions to
> crash.
>
>
Maybe you and the MontaVista guys could get together
and come up with a common cross-compilation plan.
Speaking of which, we actually started a sourceforge project just
recently to host the cross crash patch we are going to attempt to
maintain against crash as well as we can. Just haven't gotten around to
announce to everyone yet, so I guess here it is. Our latest so far is
against 4.0.3.17. Additional community contributions are definitely most
welcome. Just email me your sourceforge info and I'll add you as a
developer if there is any interest.
http://sourceforge.net/projects/crosscrash
10:49 a.m.
Dave Jiang wrote:
Dave Anderson wrote:
> "Wright, David" wrote:
>
>
>> Hi Dave,
>>
>> This seemed like the perfect opportunity to ask if this proves
>> there might be a market for my cross-compilation additions to
>> crash.
>>
>>
>
> Maybe you and the MontaVista guys could get together
> and come up with a common cross-compilation plan.
>
Speaking of which, we actually started a sourceforge project just
recently to host the cross crash patch we are going to attempt to
maintain against crash as well as we can. Just haven't gotten around to
announce to everyone yet, so I guess here it is. Our latest so far is
against 4.0.3.17. Additional community contributions are definitely most
welcome. Just email me your sourceforge info and I'll add you as a
developer if there is any interest.
http://sourceforge.net/projects/crosscrash
Nice -- thanks for persuing this.
Dave
6302
days inactive
6304
days old
devel@lists.crash-utility.osci.io
9 comments
5 participants
participants (5)
-
Dave Anderson -
Dave Jiang -
Ming Zhang -
Rainer Bawidamann -
Wright, David