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

-----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 |