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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
