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:
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: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
11:05 a.m.
"Wright, David" wrote:
Maybe you and the MontaVista guys could get together
and come up with a common cross-compilation plan.
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?
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]
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:
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
6606
days inactive
6608
days old
devel@lists.crash-utility.osci.io
9 comments
5 participants
participants (5)
-
Dave Anderson -
Dave Jiang -
Ming Zhang -
Rainer Bawidamann -
Wright, David