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