[Crash-utility] Re: EFBIG with gdb - to you hack gdb to pass O_LARGEFILE in the files open() flags?

[Dave Anderson]

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