6:03 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dave:
I was wondering why gdb isn't having a problem with the crash file
being too big when started with crash yet when handing the
vmcore directly to gdb it gets an error while opening the file EFBIG.
Did you hack gdb to get around this.
Seems to be done on 32 bit code when file is too large. Looks like the
system call will ignore this if O_LARGEFILE is set:
- -------------------------------------------------------------------------
/*
~ * Called when an inode is about to be open.
~ * We use this to disallow opening large files on 32bit systems if
~ * the caller didn't specify O_LARGEFILE. On 64bit systems we force
~ * on this flag in sys_open.
~ */
int generic_file_open(struct inode * inode, struct file * filp)
{
~ if (!(filp->f_flags & O_LARGEFILE) && i_size_read(inode) >
MAX_NON_LFS)
~ return -EFBIG;
~ return 0;
}
-
---------------------------------------------------------------------------
The system making the core file is likely running in 32 bit mode
but it has a lot of memory, likely 4GB.
MemTotal: 3,557,132 kB
This old 2.6.16 kernel doesn't know that the processor can run in
64 bit mode. Both gdb and crash were build in the same 'build' env
and appear to be the same version.
- -piet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH0S8oJICwm/rv3hoRAgJjAJoCymCnNVei16pll4wdhZnP+NKXLgCcDYlY
r2K8cYee2j4SdcZ1xkuB15w=
=iott
-----END PGP SIGNATURE-----
7:51 a.m.
Pete/Piet Delaney wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dave:
I was wondering why gdb isn't having a problem with the crash file
being too big when started with crash yet when handing the
vmcore directly to gdb it gets an error while opening the file EFBIG.
Because the embedded gdb module in crash doesn't have a clue
about dumpfiles. It's invoked internally simply as "gdb vmlinux"
in order to get the symbol values, debuginfo data, etc.
When you bring up gdb on just a binary executable you can still
issue gdb commands that in turn generate read commands from the
the executable. But one of the many hacks to the embedded gdb module
is to hijack any read attempts, and pass them back up to the
crash-based module for resolution.
Dave
7:03 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Dave:
|>
|> I was wondering why gdb isn't having a problem with the crash file
|> being too big when started with crash yet when handing the
|> vmcore directly to gdb it gets an error while opening the file EFBIG.
|
| Because the embedded gdb module in crash doesn't have a clue
| about dumpfiles.a
But the stock gdb knows how to read kexec vmcore files. Right?
| It's invoked internally simply as "gdb vmlinux"
| in order to get the symbol values, debuginfo data, etc.
Right it's not accessing the core file directly.
|
| When you bring up gdb on just a binary executable you can still
| issue gdb commands that in turn generate read commands from the
| the executable.
Right but I want to use ddd on the core file in addition to crash
to browse data structures with the data window. I use it all the time
with kgdb. Problem is here the panic is holding a spinlock and KGDB
over ethernet doesn't work when a spinlock is held. KGDB over serial
isn't working in my image last I tried to use it.
| But one of the many hacks to the embedded gdb module
| is to hijack any read attempts, and pass them back up to the
| crash-based module for resolution.
I was thinking of just pulling one of the DIMMS and getting memory low
enough that gdb isn't confused.
- -piet
|
| Dave
|
| --
| Crash-utility mailing list
| Crash-utility(a)redhat.com
| https://www.redhat.com/mailman/listinfo/crash-utility
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH0eX/JICwm/rv3hoRAk8vAJ0b++xC00j+GGx8FD+T0dtiRPsTFwCeIbml
iGaLrvN9s/EtIoCOjw6Nj+0=
=1s4/
-----END PGP SIGNATURE-----
9:12 a.m.
Pete/Piet Delaney wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Dave:
|>
|> I was wondering why gdb isn't having a problem with the crash file
|> being too big when started with crash yet when handing the
|> vmcore directly to gdb it gets an error while opening the file EFBIG.
|
| Because the embedded gdb module in crash doesn't have a clue
| about dumpfiles.a
But the stock gdb knows how to read kexec vmcore files. Right?
I don't know whether the stock 32-bit gdb knows how to read the default-sized
64-bit kdump ELF vmcores (yet). If not, you can configure kudmp to create
32-bit ELF vmcores in /etc/sysconfig/kdump here in Red Hat environments:
# Any additional kexec arguments required. In most situations, this should
# be left empty
#
# Example:
# KEXEC_ARGS="--elf32-core-headers"
KEXEC_ARGS=" --args-linux"
But that will clip off the memory above 4GB (if it would even work at all).
But w/respect to the file size issue, that's a different issue.
| It's invoked internally simply as "gdb vmlinux"
| in order to get the symbol values, debuginfo data, etc.
Right it's not accessing the core file directly.
|
| When you bring up gdb on just a binary executable you can still
| issue gdb commands that in turn generate read commands from the
| the executable.
Right but I want to use ddd on the core file in addition to crash
to browse data structures with the data window. I use it all the time
with kgdb. Problem is here the panic is holding a spinlock and KGDB
over ethernet doesn't work when a spinlock is held. KGDB over serial
isn't working in my image last I tried to use it.
| But one of the many hacks to the embedded gdb module
| is to hijack any read attempts, and pass them back up to the
| crash-based module for resolution.
I was thinking of just pulling one of the DIMMS and getting memory low
enough that gdb isn't confused.
Or just put mem=XXXg on the boot command line?
Dave
7:19 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Dave:
|>
|> I was wondering why gdb isn't having a problem with the crash file
|> being too big when started with crash yet when handing the
|> vmcore directly to gdb it gets an error while opening the file EFBIG.
|
| Because the embedded gdb module in crash doesn't have a clue
| about dumpfiles. It's invoked internally simply as "gdb vmlinux"
| in order to get the symbol values, debuginfo data, etc.
I just thought, gdb can't get thread info from a core file
like kgdb can via the simulated ptrace or /proc interface.
There are other problems; for example ddd is passing a -q
option to gdb and crash doesn't know what to do with it.
I don't suppose anyone has hacked ddd to access gdb via crash.
There's a --debugger option to ddd but as I recall with crash
gdb commands need to be prefixed with 'gdb' so the data browser
wouldn't know to do that.
- -piet
|
| When you bring up gdb on just a binary executable you can still
| issue gdb commands that in turn generate read commands from the
| the executable. But one of the many hacks to the embedded gdb module
| is to hijack any read attempts, and pass them back up to the
| crash-based module for resolution.
|
| Dave
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH0emIJICwm/rv3hoRAgKRAJ0d0BTMFl0LB04CI+5oevgDnNRISwCdGyTc
MTsqK7edWFpCGTo1Y6mKNPU=
=LgRQ
-----END PGP SIGNATURE-----
6105
days inactive
6108
days old
devel@lists.crash-utility.osci.io
4 comments
2 participants
participants (2)
-
Dave Anderson -
Pete/Piet Delaney